[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