VVID is the right direction. However I think 'VVID' is unnecessarily
biased terminology. People might use the GMPI interface to do all
sorts of things other than synth/samplers. Really what we're talking
about is more of a virtual -process- ID, so more like 'VPID'.
Here I mean that in a synth plug, a note-on spawns a virtual process with a VPID, subsequent controllers/parameters using that same VPID are routed to that same process, and when the note dies inside the plug, the VPID becomes invalid because there is no longer any living process with that VPID.
Now imagine a plug that responds to a note-on by creating a graphic sprite instead of a note. They dynamically come in and out of existence just like notes in a synth, and while they're alive you can send commands and setParam msgs to them such as color, position, transparency, shapesArray, animation state, etc. Each sprite isn't a voice, but it's still a virtual process.
Or imagine a plug that responds to a note-on by creating a Max-like event processing module and inserting it in a chain (or patched network) that's inline with the plug's control input port, internal to the plug. Once it exists you can send commands and setParam msgs to the same VPID to select a module class, set the position in the chain/net, and set operating parameters. Each module isn't a voice, but it's still a virtual process.
Etc. etc. etc. So I suggest using the terminology VPID instead of VVID. Besides, VV looks like a W in the font I read mail in, and that's standards-speak for Work Item Description, a topic that always causes extreme pain, and so I wince every time I see it. ;-)
About the relationship between the controller type and voice allocation: Under this whole VPID model, it's up to the original controller (or I guess optionally the host can re-process the sequence) -- but not the plug -- to decide whether using a guitar controller should produce 1-voice-per-string behavior vs. 1-voice-per-note-on behavior. In real life, speaking as a GR-1 user, I'd suggest this needs to be thought of not strictly as a fixed permanent mode of the controller, but instead as some sort of dynamically configurable thing that's somehow tied in with the design of the selected patch -- when controlling something like a vibes patch, it just sounds wrong (and not very often interestingly wrong, usually just wrong wrong) to lose the ring-out of the last note every time you hit a new one (which is what happens with 1-voice-per-string).
If all plugs use the VPID model, then any plug can work either way, which seems like good general-purpose design. However if you also want the results to sound right, then you might indeed want the selected patch's preferred way to be able to back-propagate all the way to the controller. Don't know how, exactly One way around this is for the plug to decide it'll use the key number in the note-on as its VPID and ignore the transmitted VPID. Nothing can prevent a given plug author from doing it this way anyway. However then the ability to have two notes on the same key at the same time is lost... maybe that's OK?
-- Chris G.
---------------------------------------------------------------------- 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