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

[robbins jacob]

>>It's obvious when you consider that "VVID has no voice" can happen 
>>*before* the synth decides to start the voice; not just after a voice has 
>>detached from the VVID as a result of voice stealing. At that point, only 
>>the value of the control that triggered "voice on" will be present; all 
>>other controls have been lost. Unless the host/sender is somehow forced to 
>>resend the values, the synth will have to use default values or something.

>OK... I was thinking that the initial mention of the VVID would cause it 
>creation (be that implicit or explict, though I prefer explit I think), 
>thereafter control changes would be applied the the instantiated voice (or 
>the NULL voice if you've run out / declined it).

The initial mention of the VVID is the issue here; certain types of voice 
events are assumed not to allocate a voice (parameter-set events). THis is 
because there is no difference between a tweak on a VVID that has had its 
voice stolen and a tweak intended to initialize a voice that arrives before 
voice-on. We must conclude that the plugin will discard both of them. There 
must be a signal to the plugin that a VVID is targeted for activation. we 
have a few options:

---a voice-activation event is sent, then any initializing events, then a 
voice-on event

---a voice-on event is sent, with any following events on the same timestamp 
assumed to be initializers

---a voice-activation event is sent and there is no notion of voice-on, one 
or more of the parameters must be changed to produce sound but it is a 
mystery to the sequencer which those are. (I don't like this because it make 
sequences not portable between different instruments)

---events sent to voiceless VVID's are attached to a temporary voice by the 
plugin and which may later use that to initialize an actual voice. This 
negates the assumption that voiceless VVID events are discarded.


   #2 is just an abbreviated form of #1, as i argue below. (unless you allow 
the activate-to-voice_on cycle to span multiple timestamps which seems 
undesireable)

> > > > When are you supposed to do that sort of stuff? VOICE_ON is > > > 
>what triggers it in a normal synth, but with this scheme, you > > > have to 
>wait for some vaguely defined "all parameters > > > available" point.
We can precisely define initialization parameters to be all the events 
sharing the same VVID and timestamp as the VOICE_ON event. This means that 
the "all parameters available" point is at the same timestamp as the 
VOICE_ON event, but after the last event with that timestamp.

If we want to include a VOICE_ALLOCATE event then the sequence goes: 
timestamp-X:voice-allocate, timestamp-X:voice-parameter-set(considered an 
initializer if appropriate), timestamp-X:voice-on, timestamp-X+1:more 
voice-parameter-sets (same as any other parameter-set)

But this sequence can be shortened by assuming that the voice-on event at 
the last position for timestamp-X is implicit:  
timestamp-X:voice-on(signifying the same thing as voice-allocate above) 
timestamp-X:voice-parameter-set(considered an initializer if appropriate), 
(synth actually activates voice here), timestamp-X+1:other-events


---Jacob Robbins.................








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