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

[David Olofson]

On Tuesday 07 January 2003 20.42, robbins jacob wrote:
[...]
> >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

That should work, and allows normal Voice Controls to be used as 
initializers.

Also note that nothing says that the synth must allocate a *physical* 
voice for this; it could start with a non-playing virtual voice and 
allocate a physical voice only when it decides to actually make some 
noise. (Or decides to ditch the voice, based on the state of the 
initializers when "voice on" is triggered.)


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

That breaks control/initializer compatibility totally. Initializers 
cannot be Voice Controls if they're special-cased like this.


> ---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)

Sequences are still "portable" if controls are hinted in a sensible 
way. Obviously, you can't make a "note on velocity" synth play 
continous velocity sequences properly, but there isn't much that can 
be done about that, really. The note on velocity data just isn't 
there.


> ---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.

Sort of. It's hard to avoid this if initializers really are supposed 
to have any similarities with controls, though.

Also, I don't think it's much of a problem. When you run out of 
voices, you're basically abusing the synth, and problems are to be 
expected. (Though, we obviously want to minimize the side effects. 
Thus voice stealing - which still works with this scheme.)


>    #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)

Well, you can't really prevent it, if initializers are supposed to be 
control values, can you?


> > > > > 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.

Yes - but that's not compatible with standard Control sematics in any 
way...


> 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.

And that point is a bit harder for synths to keep track of than 
"whenever voice on occurs." This is more like script parsing than 
event decoding.

No major issue, but the special casing of initializers is, IMO.


> 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

The latter isn't very different from assuming that the first control 
event that references a VVID results in a (virtual or physical) voice 
being allocated. In fact, the synth will have to do *something* to 
keep track of controls as soon as you start talking to a voice, and, 
when appropriate, play some sound. Whether or not the synth allocates 
a *physical* voice right away is really an implementation issue.

VOICE_ALLOCATE is really just a way of saying "I want this VVID 
hooked up to a new voice - forget about whatever it was connected 
to." You don't *have* to send one for every note, although you'll 
probably want to, most of the time. It's a separate feature, and 
doesn't imply anything about voice allocation; that's what I'm 
actually trying to say.


So... Maybe we should actually just go back to the original idea of 
"DETACH_VVID", but instead use it right before we want a VVID to be 
attached to a new voice? (The original idea was to send a DETACH_VVID 
"some time" after you're done with a voice.)

That way, the first Voice Control Change for a VVID implicitly and 
"indirectly" causes voice allocation, as a result of no voice (or 
some sort of marked fake voice - synth implementation dependent) 
being attached to the VVID.

Obviously, this eliminates the need for senders/hosts to clear any 
VVID entries and that kind of mess. (And thus, the requirement that a 
cleared/unassigned VVID entry is 0 or NULL.) Just make sure to send a 
DETACH_VVID before you use any VVID the first time.


//David Olofson - Programmer, Composer, Open Source Advocate

.- The Return of Audiality! --------------------------------.
| Free/Open Source Audio Engine for use in Games or Studio. |
| RT and off-line synth. Scripting. Sample accurate timing. |
`---------------------------> http://olofson.net/audiality -'
   --- http://olofson.net --- http://www.reologica.se ---