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