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 ---------------------------------------------------------------------- Generalized Music Plugin Interface (GMPI) public discussion list Participation in this list is contingent upon your abiding by the following rules: Please stay on topic. You are responsible for your own words. Please respect your fellow subscribers. Please do not redistribute anyone else's words without their permission. Archive: //www.freelists.org/archives/gmpi Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe