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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] more on XAP Virtual Voice ID system
From: Tim Hockin (thockin_AT_hockin.org)
Date: Wed Jan 08 2003 - 11:01:30 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed Jan 08 2003 - 11:10:09 EET