8 Jan
2003
8 Jan
'03
5:07 a.m.
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.