[OSC_dev] Keyboard Controller Keys vs Voices

Fri Jan 16 12:11:47 PST 2009

On Fri, Jan 16, 2009 at 2:55 PM,  <werteplus at gmail.com> wrote:
> 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)

Hi,

I just wanted to mention that this is basically describing what we
implemented last year using Max/MSP.  The patches to create
synthesizers and controllers are available for download if anyone's
interested.  The system provides a GUI showing what synthesizers and
controllers are on the network (using multicast), and the user can set
up connections from controllers to synthesizers which become
peer-to-peer connections.  Then connections between particular
namespace items can be made, with some signal conditioning such as
scaling and filtering if requested.

http://idmil.org/software/mappingtools

I also started working on a C version of this protocol but it's not
near done yet.  The synthesizer side is sort of working but the
controller side is more complicated because it maintains several
connections.

In terms of namespace, we usually have the controller provide several
"levels" of control: the "raw" sensor data (such as key on/off), then
also "smoothed" or conditioned data, and finally  higher level data
such as features that are extracted from combined sensor information.
This part of the work is greatly inspired by the GDIF ideas, described
here:

http://www.hf.uio.no/imv/forskning/forskningsprosjekter/musicalgestures/gdif/index.html

So correspondingly we prefix the namespaces with /raw, /cooked, and
/instrument.  (and maybe others)

Steve

> 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
>> ***************************************
>
>
> _______________________________________________
> OSC_dev mailing list
> OSC_dev at create.ucsb.edu
> http://lists.create.ucsb.edu/mailman/listinfo/osc_dev
>
>