[OSC_dev] Keyboard Controller Keys vs Voices

[werteplus at gmail.com]

hey salsaman,

i thought a bit more about the voices concept and what if a controller just
sends "this hardware key on/off" messages (+velocity, etc) as you would
prefer. that system surely has some allurement too.

Sure, but you don`t need to limit it to one mapping per key. Or you could
> allow several "modes" of a key to be active at once.
>
> Also, LiVES uses virtual keys - some are mapped to the keyboard, some are
> not, in reality these are simply slots which things can be mapped to.
>

that would be necessary that a key can map itself to a frequency / cent
offset to a base frequency / ratio to a base frequency (this one is my
favourite).

BUT one problem came to my mind with a system where the synthesizer has to
know + handle which key is which frequency: what if a second controller has
a different mapping and sends this mapping to the synthesizer?

either: a) the keys of the two controllers "overlap" and the first one now
triggers a different frequency for each key (yuk)

or: b) each controller has its own "namespace" at the synthesizer. this is
the more preferable way to go with the keys concept in my opinion. but the
synthie will have to handle a table for every controller connected =>
connection handshakes become necessary and no more optional + the controller
will probably have an upper limit for simultaneously connected controllers
which also depends on the keys per controller.

i try to be open here, but are these things justifyable in your opinion? (no
sarcasm)

greetings,
fabb


On Thu, Dec 25, 2008 at 8:17 PM, <osc_dev-request at create.ucsb.edu> wrote:

> Date: Thu, 25 Dec 2008 18:42:13 +0100 (CET)
> From: salsaman at xs4all.nl
> Subject: Re: [OSC_dev] Keyboard Controller Keys vs Voices
> To: "Developer's list for the OpenSound Control \(OSC\) Protocol"
>        <osc_dev at create.ucsb.edu>
> Message-ID:
>        <4420.189.81.132.212.1230226933.squirrel at webmail.xs4all.nl>
> Content-Type: text/plain;charset=iso-8859-1
>
> On Thu, December 25, 2008 15:35, werteplus at gmail.com wrote:
> >>
> >> Conclusion: there is a need for further standardization in order to
> >> ease compatibility. At least at the "send note" level. But this is a
> >> *big* thing. For example, I think a new implementation of midi should
> >> avoid the 12 notes per octave division. For example, I would like my
> >> keyboard to send the notes from the "Pythagorean tuning" with the base
> >> scale being changed as I play. If we want compatibility at the midi
> >> level but from osc devices that are much more clever, we should use a
> >> translating software from the "better advanced musical thing" to the
> >> "too limited midi". Rubyk would be ideal for this: you write the
> >> mappings in a Lua script. It could even be a standard object
> >> "Synoscopy" that does just the translation between "clever, fine
> >> musical thing" to "midi".
> >>
> >> Season's Greetings to you all !
> >>
> >> Gaspard
> >>
> >
> > totally right! because of this i considered microtuning as a basic
> concept
> > of synoscopy. so every key can get linked by a simple method to a new
> > frequency. that AND that a "voice on" message accepts either the note
> > number
> > OR the desired FREQUENCY! this is very important in my opinion. so a
> > controller can 100%ly decide which note should get played without messing
> > with a channel pitch bend as actually necessary in midi.
> >
> > funny you said that about the pythagorean tuning, as i'm actually
> > conceiving
> > a new tone system with a dynamic changeable base frequency at the moment!
> > (the beehive, i'm at resolving layout questions now)
> >
> > a 100% translation isn't possible as due to the pitch bend problem in
> > midi.
> > e.g. in the continuum fingerboard, individual pitches are only allowed
> for
> > 10 simultaneous voices (it could be 16 as there are 16 midi channels).
> but
> > a
> > further problem would be that the pitching would also affect notes
> > received
> > from other sources... horrible.
> > http://www.hakenaudio.com/Continuum/html/operation/MidiOutput.html
> >
> >
> > I wonder if there is an analogy between the musical keys on a MIDI
> >> keyboard and the (video) effect keys in LiVES ? The idea is basically
> >> the
> >> same. Of course in LiVES, one can map individual effects onto effect
> >> keys,
> >> so an analogy of this would be mapping musical tones to the keys on a
> >> music keyboard. Also in LiVES, each key has a "mode" which goes from 0
> >> to
> >> 7 (usually) and a different effect can be mapped to each mode (thus
> >> giving
> >> a "bank" of effects to each key, which can be triggered from the
> >> keyboard).
> >>
> >> So to get your pythagorean keyboard you would use the same syntax as in
> >> LiVES, except that you would map a tone to an key (and mode), thus:
> >>
> >> /key.n(.m)/map 2200
> >>
> >> would map a tone of 2200 Hz (or whatever equivalent for a sample), to
> >> key
> >> n (mode m)
> >>
> >> then:
> >>
> >> /key.n/enable (which is a synonym of /key.n 1 or /key.n/set 1)
> >>
> >> to play that note, and:
> >>
> >> /key.n/disable
> >>
> >> to switch the note off:
> >>
> >> /key.n/toggle
> >>
> >> to toggle it.
> >>
> >> Continuing the LiVES metaphor, you would have:
> >>
> >> /key/count
> >> /key/map/clear
> >> /key/reset             (switch all keys off)
> >>
> >> /key/mode(/set) (/get)        set and get the mode for a key
> >>
> >> I wonder if this would make sense and work for a musical keyboard.
> >>
>
> >
> > i'm against this usage as it would be too much of the old midi way of
> > "only
> > one activation per key". thinking more complex, several simultaneously
> > playing voices could be activated by one key (!) and vice versa. and
> > voices
> > don't necessarily have to get activated by real keys, but could by an
> > algorithm.
> > further things are velocity and other parameters which apply to the
> > initial
> > activation of a voice.
>
> Sure, but you don`t need to limit it to one mapping per key. Or you could
> allow several "modes" of a key to be active at once.
>
> Also, LiVES uses virtual keys - some are mapped to the keyboard, some are
> not, in reality these are simply slots which things can be mapped to.
>
> Anyway, maybe something for you to consider if the other way doesn`t work
> out as you had hoped.
>
>
> >
> > it's the question, which mentality to prefer:
> >
> > 1) the midi way: a controller sends what keys are pressed/released and
> the
> > receiving synth interprets them.
> >
> > 2) the synoscopy way: a controller directly manipulates voices of the
> > synth
> > by sending voice on/off with that
> > notenumber/frequency/velocity/cutoff/etc.
> >
> > i (obviously) prefer the second way. let's say it this way: a controller
> > that knows that it's dealing with a synth can take advantage of way 2,
> and
> > a
> > dumb "allround" controller will only be able to use way 1 and tell what
> > happens to him (ie what of its buttons are held down).
> >
> > it's really the question which way to go. or let both be possible?
> > http://synosc.wetpaint.com/page/Overview
> >
> > greetings,
> > fabb
> > _______________________________________________
> > OSC_dev mailing list
> > OSC_dev at create.ucsb.edu
> > http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
> >
>
>
>
>
> ------------------------------
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>
> End of OSC_dev Digest, Vol 57, Issue 23
> ***************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.create.ucsb.edu/pipermail/osc_dev/attachments/20090116/700cf260/attachment.html