On Tuesday, November 29, 2005 10:23 PM [GMT+1=CET],
thockin@xxxxxxxxxx <xxxthockin@xxxxxxxxxxxxx> wrote:
On Tue, Nov 29, 2005 at 12:24:42PM -0800, Chris Grigg wrote:
(1) One of the examples had messages addressed to things called v0 &
v1, but usually you want the plug to do voice allocation. So what's
up with that?
Virtual voice IDs. The host has an idea of all the voices it has
requested be started. Thos voices map to real voices inside the plugin
according to plugin-defined rules. The host should only operate on
virtual voices.
In some (very primitive) system I once made, when you started a new "note"
(I actually prefer "musical object" but anyway...) you can send the "start
new note" event to the plugin that must start a new voice for it, and the
plugin returns a voice ID, that the host can store for later referencing. I
also seem to recall I added the possibility for the host to specify the
voice ID directly that should be used for the new voice (instead of letting
the plugin choose one), but I don't really recall why I added that...
The plugin can assign its voices as it sees fit, but should let the host
know the ID of the voice for later reference.
There's just one thing I remember not being sure about how to handle it: a
note off message does not kill the voice right away, and the corresponding
voice ID will be alive for the rest of the release part of that note, during
which you may stil want to bend its pitch etc... The time when the note
really stopped is determined by the plugin itself, and in order to let the
host know that the voice has eventually completely died, there should be a
mechanism that allows the plugin to tell the host that the corresponding
voice ID has become free again.
Does this sound reasonable?
>> (2) If you separate out all the parameters into separate messages,
how does the plug know when the sender's finished sending parameters?
If it's just waiting for the 'turn note on' message, then
To keep up this particular example idea: You send all of the parameters
that apply to the start of a voice at the same timestamp as the voice-on.
When you hit the next timestamp, you've got them all and can process that
voice-on.
(a) is it -really- reasonable to rely on senders to always do the
'turn note on' message last?
(b) Can you -really- rely on the pipes to always preserve message
transmission order (think TCP/IP etc.)?
Nope. I have somewhere an older email that talks about this - you need to
process all the events for a sample frame before generating audio for that
frame.
That's more or less similar to what is done in VST now when you're using
MIDI events to get sample-accurate parameter changes, right? First the host
calls your plugs processEvents function during which you receive all MIDI
events for the about-to-be-processed audio buffer, and only then the process
function is called that actually does the audio processing stuff, taking
into account the timestamps and semantics of the parameter changes that are
done via the MIDI events (usually CC's).
Koen
