new instrument design (was Re: Compositional methods)

>>() Learn C... in the context of writing drivers (yuck!), for work.
>
>Oh well, there you are using it where it is really in its element,
>near assembly level.

That's what they tell me.

>Do you know the obfuscated c competitions?
/.../
> http://jtull.rutgers.edu/~rhoads/Obfuscated_C/obfuscate.html
/.../
>Check out the adder program - consisting of multiple
>copies of the word Main with various combinations of lower
>and upper case for the letters, and nothing else much
>except #defines.

Wild!

>Quite a lot happened since then, but I notice the last beta upload
>proper is in january or something - i've been doing extensive
>changes and just had "beta previews" since then, new look for
>main window, & I think easier to navigate + multiple output
>ports and a few other goodies like FFT. Hope to do new beta
>proper soon, and then release soon after that, once help is ready.

Can I be on your mailing list?

>Suppose in main channel c is 1/1 of your j.i. scale. (where 1/1 is
>arbitrarily set to some absolute pitch, say, concert pitch C). Then
>E is the 5/4 above this.
>
>That has to correspond to some root in the root channel, and suppose
>for definiteness that your c = 1/1 as default when no key has yet
>been pressed, and the same when key C is pressed.
>
>Now when you change the root to, say, F in the root channel, i.e.
>the F of the mean-tone scale, or whatever, question is, what happens
>to the E. Is it still 5/4 above something?

Not in my scheme. That would seem to require large pitch shifts
for keys on the main keyboard (?). In my scheme, choosing F simply
indicates the pitch at which the sequence of intervals starting at
1/1 is centered. The pitch can come from the control keyboard,
in which case the total accessible tuning is limited to the cross
set of the two scales, or it can come from the main keyboard, in
which case the total accessible tuning is infinite. All this
will be made clear in the spec, which is half-finished as of 2am
last night. BTW, I do not mean to enforce my ideas with the spec...
it's just that I need to make my ideas more clear, for myself, and
if I intend to share them efficiently with others.

>If one did it same way as the tonaility diamond, just multiplying
>the value in the root channel by value in the main channel,
>then you'll get it E -> 5/4 * (value for F), and so 5/4 above the F.
>
>I.e. when you press the F for the root, then the just intonation
>12 tone scale from c to c' is still the ji. 12-tone, but this
>time the c playes an f, because you have shifted everything up by
>the interval c - f in the root channel.

No, we don't want that... large pitch shifts of the main keyboard
would make it very hard to play, and nothing more than a glorified
version of a "transposing keyboard"... an idea hundreds of years
old... though I'm told Irving Berlin could only play in F#, and had
a transposing keyboard to get around this!

>However, more natural idea might be to make it the 8/9 (or whatever)
>below the F of the root channel, so that it still sounds as a note
>somewhere in the vicinity of concert pitch E.

Correct -- that's my idea. It's still just multiplication, except
you're making sure to keep 1/1 on the same physical key on the
main keyboard (there's a 1/1 in every scale in the tonality diamond,
remember). The possible pitches of every other physical key are
then found on the diagonals of the diamond.

>However, with tonality diamond, with no note names to want to
>preserve, I think one would find it easier to navigate if the two
>keyboards were just the two axes of the diamond, and the note
>played was the product of the two.

Well, I'll disagree, but that doesn't mean I wouldn't like to
try this method!

>Obviously use most of the same code for both, but would need a
>couple of extra lines (maybe more) for one of them.
>
>Is that any clearer yet?

Yes -- hopefully for you too. Thanks, Robert, for this highly
productive discussion.

>>But most importantly, such a package would support custom staff
>>design... so you could map, for example, something like Paul
>>Erlich's decatonic scale to successive staff positions, and use
>>it like a diatonic scale! No score entry software I know of even
>>claims to support this behavior.
>
>Ah, this last you can do with midi relaying, to reasonable first
>approx. I use it all the time, using NoteworthyComposer (which
>happens to be the score editor I use), but it will work with any.

Why didn't I think of that?

I knew you used NWC, which I haven't tried in years, but I didn't
know you used this technique!

>Just add a note to the score saying what mapping you use, which
>can be any mapping of midi notes of the stave to pitches that
>you like. That's for oneself, so that you will know what mapping
>to use in future, by reading the score.
>
>Then relay it with that mapping. I use Hubi's loopback, a free
>software driver that relays midi out of one prog. to midi in of
>another. I think there is another driver that does the same thing.

Midi Yolk, which I use all the time.

>If you look at the scores for most of the pieces on my tunes page,
>then you'll see that they are done this way.
>
> http://robertinventor.tripod.com/tunes/tunes.htm

When I get into work, I'll grab everything off your page.

>So I can play them any time just by setting up the mapping
>in FTS and playing them in NWC. In fact one could also save them
>as 12-tet midi files and relay them with the mapping from those
>too.

Right.

I've always used Breed's Midi Relay, but it has a key repeat
bug, where notes revert to 12-tET. How does FTS do?

>I'm surprised how few seem to use this technique. Mats Oljare does,
>using Graham Breed's program for midi relaying in his case.

I thought he used Cakewalk piano roll view... is he a NWC convert?

>I often do it so that repeats of the scale are shown as octaves in
>the score, so if it is say, 6 notes pad the scale out with one
>extra note to make it a 7 note scale, and relay it from successive
>white notes.
/.../
> If non octave scale, may do it so that the non octave repeat is
>shown as "octaves" on the score.

Not sure what you mean here... why is octave repeating important?

>It is only a first approx because a proper microtonal score editor
>would let one vary the number of lines in the stave and things like
>that, and use microtonal accidentals and so forth.

Right. Well, Sibelius I believe does allow custom staves to some
extent. Microtonal accidentals are really important to the scheme...
we need to look into the custom accidental features of Sibelius and
Finale...

>> Yep. Are you familiar with the notion of the generalzed keyboard?
>
>No, didn't realise it was a specific concept. Can you say more,
>or give ref?

Well, it just so happens I have a document for that purpose.
Some of the links may have changed at the Wilson site, since
Kraig went over to pdfs. See also "Janko keyboard", and the
patents listed at www.daskin.com. Take some time to look
into this one... I think you'll be interested. To summarize:

() Conventional keyboard is better for 12-tET than many
theorists give credit, but is not optimal. Something like
Vandervoort's (daskin.com) Janko arrangement is superior.

() For alternate tunings, conventional (aka halberstadt)
keyboard is next to useless.

() Tuning and optimum digital layout are relatively
independent. Thus, design the optimum digitals, and map
any tuning you like (hence, "generalized").

----------------------------------------------------------------

Some important references on the subject of microtonal keyboards:

<1.>
_An Elementary Treatise on Musical Intervals and Temperament_
R.H.M. Bosanquet, London, 1876.
Edited by Rudolph Rasch, The Diapason Press, Utrecht, 1987.

<2.>
Douglas Keislar, "History and Principles of Microtonal Keyboards,"
_Computer Music Joural_, Spring 1987, pp. 18-28.

<3.>
Wendy Carlos, "Tuning: at the crossroads,"
_Computer Music Journal_, Spring 1987, pp. 29-43.

<4.>
Erv Wilson,

"Bosanquet -- A Bridge -- A Doorway to Dialog,"
_Xenharmonikon 2_, http://www.anaphoria.com/xen2.html

"On Linear Notations and the Bosanquet Keyboard,"
_Xenharmonikon 3_, http://www.anaphoria.com/xen3.html

"On the Development of Intonational Systems by Extended Linear Mapping,"
_Xenharmonikon 3_, http://www.anaphoria.com/xen3b.html

"D'Allesandro, Like a Hurricane,"
_Xenharmonikon 12_, http://www.anaphoria.com/dal01.html

"Keyboard Schemata from the Scale Tree,"
_The Wilson Archive_, http://www.anaphoria.com/key.html

-Carl