[OSC_dev] Keyboard Controller Keys vs Voices

Gaspard Bucher gaspard at teti.ch
Thu Dec 25 11:46:49 PST 2008


Thanks for the link ! I did not know anything about this controller... Amazing.

Gaspard.

On Thu, Dec 25, 2008 at 3:35 PM,  <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.
>>
>> Best wishes and seasons greetings to all !!!
>> Regards,
>> Gabriel.
>
> 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.
>
> 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
>
>


More information about the OSC_dev mailing list