| >Michael Gogins wrote:
>> Again, I think the best approach is to keep the MIDI semantics but change
>> the data type from byte to float or double. The MIDI semantics are
>> everywhere in music technology and seem to work well enough.
>
>I like to modulate continuously-running synths; for me, MIDI's
>keyboard orientation is quite awkward. You get only one axis of
>continuous control over a playing note -- poly aftertouch -- plus
>on/off velocities. (And it's per-key rather than per-note, and the
>MIDI `semantics' leave unison overlaps undefined...) To get anything
>more useful requires that you only play one note per channel (insert
>standard rant about how sequencer software is designed around one
>particular way to map music onto MIDI), and there are only 16
>channels.
These are good points, but I think we'd farther faster by keeping the
present semantics and adding new status IDs for new control messages that
you need, etc.
Note that in my scheme, with all fields real, channels can be any
real-numbered value. To be more precise, my layout is:
double status (values 0 through 255 have MIDI semantics, except low
nybble is always 0; instrument number used instead; values above 255 have
new semantics).
double instrument number (can be low nybble of MIDI status field, or
numbers greater than 15).
double time in seconds (or beats)
double duration in seconds (or beats) (not required for actual
instrument control, useful for storing events in scores)
double pitch (in linear octaves, middle C = 8.0, or MIDI keys, middle C =
60.0), or data field 1.
double loudness (in decibels up from 0 = no energy, roughly maps to MIDI
velocity), or data field 2.
double phase (I added this to accomodate granular synthesis), or data
field 3... etc.
double x dimension of space, i.e. pan
double y dimension of space
double z dimension of space
|