[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