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

Tim Hockin thockin at hockin.org
Wed Jan 8 04:08:00 UTC 2003


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

All this is ok in concept.  I still think it is too implicit and it feels
'sneaky'.  I'd MUCH rather see a rigid, well-defined protocol that forces the
few bizarre instruments to do a bit more work (really, just a BIT) than a 
loose, implicit one that is going to be easy to screw up.

VOICE_ALLOCATE: declare a VID as in-use
VOICE_CONTROL_SET: set values for a per-voice control for a VID
VOICE_ON: declare that a VID is ready for play

Any VOICE_CONTROL_SET for a VID that does not exist is discarded.
I don't think there is any instrument for which this can't work.  It may not
be a perfect fit for some, but I think they are the vast minority.

This model fits and doesn't taste too bad.



More information about the Linux-audio-dev mailing list