8 Jan
2003
8 Jan
'03
7:01 p.m.
It doesn't because the host/sender doesn't
really care. A controller
or sequencer is just supposed to deliver events. It shouldn't care
more about voice activation than it does about the exact relation
between events and audio output.
OK, and we seem to agree that a VOICE_ALLOC or PREP_VOICE or something is
needed to mark that voice as re-usable.
VOICE_INIT_START
VOICE_CONTROL_SET
VOICE_INIT_STOP
It's not NAMED VOICE_ON, but it is semantically the same, yes?
If VOICE_ON
doesn't make sense for some synth, then it still makes
sense for the user.
Why? (Unless the user is a tracker die-hard.) VOICE_ON, assuming that there can be continous
velocity synths, has
a voice has to be started. Maybe not. Maybe the synth can report that it
has N voices on at all times. Hmm. Still, VOICE_ALLOC is akin to note_on.
Also, keep in mind that any feedback of this kind
requires a real
connection in the reverse direction. This makes the API and hosts
more complex - and I still can't see any benefit, really.
We already have a rudimentary reverse path.
So, how do you perform voice stealing?
You have to tell the host/sender when a voice index becomes invalid,
yep - as you point out, it requires 1-block latency.
It has none of
the problems of VVIDs.
Probably not, if I understand the above correctly.
The only problem is that it requires dialog.
That's a rather serious problem, OTOH... * no carving
of a VVID namespace for controller plugins
No, plugins have to do that in real time instead. /* find a
vvid that is not currently playing */
do {
this_vvid = vvid_next++;
while (vvid_is_active(this_vvid);
Again, this is voice allocation. Leave this to the synth.