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
