9 Jan
2003
9 Jan
'03
6:55 p.m.
> I personally find this notion bizarre and
counter-intuitive. The
> idea that the note is turned on by some random control is just
> awkward. I'm willing to concede it, but I just want to be on the
> record that I find it bizarre.
The way I see it, this "random control" that
triggers a note is
equivalent to MIDI NoteOn. It can even be a standardized NOTE control
that all synths must respond to, one way or another.
OK - in my own notes I had been referring to it as the VOICE control. You
send the VOICE control a VOICE_ON message and a VOICE_OFF message, or
simpler send 0 and 1.
comprehend,
and more consistent. I want to toss MIDI, but not
where the convention makes things easy to understand. I think that
explaining the idea that a voice is created but not 'on' until the
instrument decides is going to confuse people. Over engineered.
I think the alternative would render continous control synths even
more confusing. "Why do I have to send a VOICE_ON to make the synth
work at all?" Anyway, it's really an implementation issue. Just
don't mention it in
the API docs. Just say that the NOTE control corresponds to MIDI
NoteOn/Off. Problem solved!
So stroking the NOTE control in your mind is *identical* to sending a 1 to
the VOICE control in my mind.
The plugin CAN
use the VVID table to store flags about the voice,
as you suggested. I just want to point out that this is
essentially the same as the plugin communicating to the host about
voices, just more passively.
Only the host can't really make any sense of the data. It seems
useful.
Not really, because of the latency, the polling requirement and the
coarse timing. If the plugin
can flag VVID table entries as released, the host can
have a better idea of which VVIDs it can reuse.
Why would this matter? Again, the host does *not* do physical voice
management.
You can reuse a VVID at any time, because *you* know whether or not
you'll need it again. The synth just doesn't care, as all it will This is where the confusion/disagreement is, I think:
I don't
think of this event as "INIT_START", but rather as
"CONTEXT_START". I don't see the need for a specific "init" part
of the lifetime of a context. Initialization ends whenever the
synth decides to start playing instead of just tracking controls.
Right - this is the bit I find insane. From the user perspective:
I want to start a note. Not whenever you feel like it. Now. Here
are the non-default control values for this voice. Anything I did
not send you, assume the default. Go. A bowed string instrument is "triggered" by
the bow pressure and
speed exceeding certain levels; not directly by the player thinking
Disagree. SOUND is triggered by pressure/velocity. The instrument is ready
as soon as bow contacts the string.
The difference
comes when the host sends the 'magic' start-voice
control too soon.
Assume a synth with a bunch of init-latched controls.
Assume velocity is the 'magic trigger'.
time0: Host sends VOICE_START/ALLOC/whatever
time0: Host sends controls A, B, C (latched, but no effect from
the synth) time0: Host sends control VELOCITY (host activates
voice)
time0: Host sends controls D, E, F (ignored - they are
init-latched, and init is over!)
Do you see the problem?
No, I see a host sending continous control data to an init-latched
synth. This is nothing that an API can fix automatically. Yes, it has to be triggered by a standardized control,
so hosts
and/or users will know how to hook synths up with sequencers,
controllers and other senders.
Precisely.
If it has no voice controls, there will be no VVIDs.
You can still
allocate and use one if you don't want to special case this, though.
Sending voice control events to channel control inputs is safe, since
the receiver will just ignore the 'vvid' field of events.
I think that if it wants to be a synth, it understands VVIDS. It doesn't
have to DO anything with them, but it needs to be aware. And the NOTE/VOICE
starter is a voice-control, so any Instrument MUST have that.
has killed the voice. Thus, no need for a
"VOICE_END" or similar
event either.
The host still has to be able to end a voice, without starting a
new one. From the sender
POV:
I'm done with this context, and won't send any more events
referring to it's VVID. From the synth
POV:
The voice assigned to this VVID is now silent and passive, assumed to be more special than it really is.
NOTE/VOICE_ON/VOICE_OFF
is a gate control. What more do you need to say about it?
Only if you assume a voice lives forever, which is wasteful. Besides that,
a gate that gets turned off and on and off and on does not restart a voice,
just mutes it temporarily. Not pause, not restart - mute.
control. But
until then we need a consistent way to handle
init-latched controls. Because they ARE special. They all need to
be sent before the voice is activated.
Yes - just like you have to send MIDI Program Change *before* playing
notes. It's not really a continous control, but MIDI sequencers don't
special case it, since it's obvious enough that the user should say
what sound he/she wants *before* starting to play. YES! The same
as a VOICE_ON. or send a 1 to the VOICE control.
Describe it how you will, it tastes like VOICE_ON. Remember before
when I said I would concede this point? I lied! I might concede
VVIDs and give up on plugin-allocated VIDs, but this seems more and
more right, and you yourself talked me back into it.
Well, then we can probably conclude that most of this is a matter of
terminology confusion. :-) Either way, what I'm trying to figure out is a way
to have both
note-on latched and continous control synths do sensible things even
if the sender doesn't know which type it's dealing with.
Of course. See below again :)
I don't
like
that. Perhaps release velocity is a different control.
Yes, I think so.