[gmpi] Re: Parameters / controls / GMPI event system - refreshment

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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: