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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: [linux-audio-dev] more on XAP Virtual Voice ID system
From: robbins jacob (jacobrobbins__AT_hotmail.com)
Date: Mon Jan 06 2003 - 22:04:23 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Mon Jan 06 2003 - 22:11:38 EET