[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: thockin@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 2 Dec 2005 14:41:39 -0800
On Fri, Dec 02, 2005 at 01:36:26PM -0800, Chris Grigg wrote:
> 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'.
... snip a lot ...
> Etc. etc. etc. So I suggest using the terminology VPID instead of
> VVID.
Awesome point, well put, and great examples. I'll second this motion.
> 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.
I'm not following - it's exactly up to the plugin to decide. Now, it is
slightly more complicated for a guitar plugin to know that 2 VVIDs are the
same exact string.
Some examples, because I am wordy. Consider the case of a sequence of
three short notes of the same pitch:
VPID(0).on
VPID(0).off
VPID(1).on
VPID(1).off
VPID(2).on
VPID(2).off
In a true mono-synth, there is only one voice-process. Any envelope tail on
that voice-process is truncated when the next VPID is started.
In a guitar synth, there are some small number of voice-processes - one
for each string. Any envelope tail on a voice-process will modify the
next VPID that comes on that voice-process (and possibly modify other
voice-processes).
In a true poly-synth, there are a large number of voice-processes. Any
envelope tail on a voice-process can run independantly of any further
VPIDs that come on that voice-process.
The only complication I see is in the middle example - how do you know
that two VPIDs mean the same string? It would be obvious if the sender
knew to re-use the VPID. But that's putting plugin-specific info into the
host. Yuck.
> 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.
So maybe a plugin wants to expose it's preferred VPID allocation scheme? I
don't like it, but if it is just a suggestion, the host/user can choose to
ignore it.
We know of a few schemes:
VPID_ALLOC_SINGLE // us a single VPID for all notes
VPID_ALLOC_PERNOTE // use a single VPID per keyboard note
VPID_ALLOC_ANY // use any VPID
None of these map to a guitar synth. If you have 6 guitar strings, how do
you sequence which string a note goes on? Isn't there overlap? Some note
can be played on 2 strings, or no? The highest notes on string A overlaps
the lowest notes on string B? Sorry, I am not a guitarist.
It sounds like, to me, the only sane way to sequence a guitar synth is to
EXPLICITLY say which string you mean - for example, 1 string per channel.
In that case, the above is not needed, and I love to get rid of anything
not needed :)
> 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?
If the plugin author decides to make this limitation, I say more power to
them. If they decide to lift this limit, I say the same.
----------------------------------------------------------------------
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
Other related posts:
