[linux-audio-dev] more on XAP Virtual Voice ID system

[robbins jacob]

The main difficulty I see with the VVID system is how to initialize 
parameters on a new voice before the voice is activated with a VoiceOn 
event.

The MIDI standard deals with this by allowing 2 particular parameters, pitch 
and velocity, to be privileged as voice-on initializers. These parameters 
are included inside the MIDI Voice On message so that the instrument always 
receives them when they are needed: right when a voice is being activated. 
It has been the general feeling in LAD discussions that XAP should not put 2 
particular parameters into the Voice On event but, instead, should allow any 
parameter-set events to be intializers. How to achieve this?

In XAP, it is not sufficient to consider all parameter setting events 
received before a Voice On message to be initializers. Consider that, before 
an actual voice is attached to a VVID, all events sent to that VVID are 
discarded. For instance, if a voice is activated and then reappropriated 
halfway through a note, before the sequencer has stopped using the VVID, the 
remainder of the events which the sequencer sends on the voiceless VVID are 
simply discarded.

Furthermore, any system which requires initializers to be timestamped before 
the voice-on event forces at least a 1 timestamp delay into voice activation 
which is undesireable.

We could instead put the voice-on event at the same timestamp as the 
initializers and require that the plugin read ALL events for a particular 
time position before discarding ANY events, but this makes it more complex 
for plugins to read their events.  If the plugin found a voice-on event at 
the end of a queue section for a particular timestamp then it would need to 
loop back to the first event in the queue matching that timestamp and read 
again for any initializers.

Alternately, we could require that event ordering has 2 criterion:
-first- order on timestamps
-second- put voice-on ahead of all other event types.
A little ungainly, but effective as it frees the plugins to assume that 
they'll get voice-on first but must consider all other events on that 
timestamp as arguments to the initialization of the voice. Of course this 
only applies to events having a particular VVID on a particular channel of a 
particular plugin instance. I admit that introducing another criteria to 
event ordering is inelegant, but it is the best approach to voice activation 
that I can think of. I think that introducing any sort of mandatory 1 or 2 
timestamp delay is far worse.




-jacob robbins.... current projects: soundtank.......<BR>..........

_________________________________________________________________
STOP MORE SPAM with the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail