[gmpi] Re: 3.11 topic: Dynamic plugin structure

On Wed, Apr 28, 2004 at 04:15:02PM +0200, David Olofson wrote:
> I was going to say we also need to decide how much of the resulting 
> tree structures hosts are really required to understand - but the 
> answer to that is trivial, I think: "Nothing!"

> Provided the parameter list of a plugin includes the full name of each 
> parameter, a simple host can just treat the list as a plain 1D list 
> of unique parameter names. When the user wants to make a connection 
> (after picking a parameter from the long, messy and generally 
> annoying 1D list ;-), just grab the string and pass it to the 
> connect() method.

Well, a smart host will build a tree of parameters for each plugin, and
the leaf-nodes are real parameters and non-leaf nodes are groups.  A good
host can then group leaf-nodes under their group nodes, so there doesn't
NEED to be an annoyingly long and messy 1D list.  The list can have as
many dimensions as the plug deems necessary.

> > Grouping solves the method of grouping parameters together.  It
> > does not solve the issue of "what parameters get saved as part of a
> > single patch" vs "what parameters get saved as part of a complete
> > state dump".
> 
> Right, but once you have a way of expressing the grouping, it's 
> trivial to associate metadata and stuff with groups...

The simplest implementation of grouping is described above - implied tree
:)  Attaching metatdat to anything but leaf nodes requires more than that.

> > If we codify the 'channel' concept, then any plugin can have any
> > number of channels.  One of the properties is 'num_channels' and
> > the host must save the state for each channel.
> 
> Yeah, but it's only 1D, which IMHO, makes the whole OSC style 
> addressing thing a lot less useful. Will 1D (channel) indexing make 
> everyone happy? Does it really make anything easier? (What about 
> plugins that don't have channels at all? Would be kewl if they could 
> just ignore the whole thing.)

The advantage of making an extra dimension of identical 'channels' is that
it maps very cleanly onto MIDI.

> > Example:
> > num_channels = 3
> > params_list[] = {
> >     "master/volume",        //flagged as global
> >     "master/pan",           //flagged as global
> >     "osc/shape",            //flagged as per-channel
> >     "osc/octave",            //flagged as per-channel
> > };
> 
> Why not just plain:
> 
> params_list[] = {
>       "master/volume",
>       "master/pan",
>       "channel[0]/osc/shape",
>       "channel[0]/osc/octave",
>       "channel[1]/osc/shape",
>       "channel[1]/osc/octave",
>       "channel[2]/osc/shape",
>       "channel[2]/osc/octave",
> };

Sure.  If we decide that is the standard, then it works equally well for
the MIDI-compatible case.  It also makes the non-identical case work well.

Nice.

> The channels might as well be called "channelZero", channelOne" etc, 
> except that the "channel[N]" notation tells hosts that care, that a 
> "channel" is a class of some kind, and "channel[N]" are instances 
> thereof.

right.  The toplevel nodes 'channel' and 'master' are special.  Could be
extended.  Details don't matter right now, but this is a nice clean
model, I think.

> Yes, that would do as the minimal requirement, I think, though if we 
> use something like OSC style addressing, I don't see why we have to 
> enforce that channels should be identical. That could be part of the 
> requirements for a "fully GM compatible GMPI synth", but I think 
> other plugins should be able to use channels while just ignoring this 
> restriction, as long as it can be done without messing everything up.

Good.  Agree.  

----------------------------------------------------------------------
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: