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

[David Olofson]

On Monday 06 January 2003 22.03, Steve Harris wrote:
> On Mon, Jan 06, 2003 at 12:04:23 -0800, robbins jacob wrote:
> > Alternately, we could require that event ordering has 2
> > criterion: -first- order on timestamps
> > -second- put voice-on ahead of all other event types.
>
> This is what I was assuming was meant orignally.
>
> However you dont have to think of them as initiasiation parameters,
> voices can have instrument wide defaults (eg. a pitch of 0.0 and
> and amplitude of 0.0), and the parameter changes that arrive at the
> same timestamp can be thought of as immediate parameter changes,
> which they are.

Exactly.

These "instantiation parameters" are in fact just control events, and 
they relate to "whatever voice is assigned to the provided VVID".

The issue here is this: Where does control data go when there is no 
voice assigned to the VVID?

It's tempting to just say that whenever you get events, check the 
VVID, and allocate a voice for it if it doesn't have one.

However, it's kind of hard to implement voice allocation in a useful 
way if you don't know what control will trigger the allocation. (You 
can't discard very silent notes and that sort of stuff.)


As to event ordering, the logical way is to send "parameters" 
*first*, and then send the event that triggers the note - be it a 
specific note_on event (bad idea IMHO) or just a change of a control, 
such as Velocity.

Synth implementations will want it the other way around, though. 
Problem with that is that it breaks a fundamental rule of the event 
systems: "Events are processed in order."

What I'm saying is that if you send the "trigger" event first, 
followed by the "parameters", you require synths to process a number 
of control events *before* actually performing the trigger action. 
That simply does not mix with the way events are supposed to be 
handled.

What's even worse; the logical alternative (sending parameters first) 
results in allocation problems. Do we have to have actual Virtual 
Voices objects in synths? If so, how to allocate them? (Or rather; 
how many?) If VVIDs are global and allocated from the host, that just 
won't work. Synths would at least need to be informed about the 
number of VVIDs allocated for a Channel, when a connection is made.


Wait. There's another alternative.

If you really want to your voice allocator to be able to turn down 
requests based on "parameters", how about using a single temporary 
"fake voice" whenever you get a "new" VVID? Grab it, fill in the 
defaults and have it receive whatever controls you're getting. When 
you get the "trigger" event, check the "fake voice", and if the voice 
allocator doesn't like it, just hook the VVID up to your "null" voice.

Obviously, this requires that "parameters" are sent with the same 
timestamp as the corresponding "trigger" event - but that makes sense 
if the "parameters" are really to be regarded as such.

If they aren't, we're talking about a different problem: Keeping 
Voice Control history for Voices that aren't allocated or playing.


Anyway, this obviously suggests that it should be strictly specified 
whan you may and may not talk to a Voice and expect it to respond. I 
mean, it obviously seems stupid to have a physical voice running just 
to track Voice Controls while nothing is being played - but OTOH, 
what do you do if you have 128 VVIDs in use on a 32 voice synth? What 
do you track, and what do out send to the NULL voice? When do you 
actually steal a physical voice?


Note that all this is very closely related to implementation 
specifics of synth voice allocators. I think the issue is more one of 
coming up with a sensible API for this, than to dictate a policy for 
voice management. I doubt that a single policy can work well for all 
kinds of synths.


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