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
