[gmpi] Re: 3.11 topic: Dynamic plugin structure

On Tue, Apr 27, 2004 at 10:55:44AM +0200, David Olofson wrote:
> > 1) Does the host need to give an OK for a plugin to change its own
> > parameter list?
> 
> What would the plugin do if the host says "no"? Refuse the property 
> value that caused the plugin to want to change it's parameter 
> list...? And why would the host say "no" in the first place?
> 
> I say no. The host will just have to deal with plugins withdrawing and 
> adding controls, ports and stuff. Cleaner and simpler than the 
> alternatives, I think.

Ron, as the proposer of the host-ACk - enlighten us?

> > Secondly, we probably need a way to group parameters together.  Is
> > one level of parameter grouping enough?  Does it need to be
> > arbitrarily nested?
> 
> I think this depends on the implementation, and/or the rules for 
> changing the parameter list. The problem with something like having 
> all parameters in a single table where each parameter has an index in 
> a contiguous block, is that parameters may move around when you 
> change the layout. If parameters are to keep their indices, all you 
> can do is add/remove parameters or groups of parameters at the end of 

I think pure indices is a bad idea.  I think symbolic names is a good
answer.

> Either way, grouping in itself is IMHO just metadata. Apart from 
> dealing with variable size ranges of parameters or parameter blocks, 
> there's no need for the low level plugin API to deal with this at 
> all.

Well, it's a matter of codifying it.  If we make it a simple OSC-like rule
of parsing the string for '/' seperators to delineate groups, then that is
OK.  I think we need a simple req to address this, though.

        GMPI must support grouping of associated parameters.  Grouping may
        be arbitrarily deeply nested.

> > Thirdly, we will still have to solve multi-channel plugins - how do
> > you save a single patch vs an entire snapshot of all the channels?
> 
> The VFS style naming scheme might work for that too. If you somehow 
> mark the nodes that represent channels, hosts that care can just look 
> for those hints when the user wants to deal with stuff on a per 
> channel basis.

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".

> > And do we codify MIDI-like channels?
> 
> Optional hints, maybe? Plugins that care should mark the root node of 
> each "channel", and hint controls with their MIDI CC equivalents 
> where applicable.

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.

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
};

When the host wants to save the state of a single channel, it saves all
the per-channel parameters for that channel.  When it wants to store all
the state, it saves the master params plus all the per-channel params for
each channel.

This means that every 'channel' must have the same parameter-list, but I
*think* this is OK.  Am I correct or mistaken?  It means we would be
codifying a MIDI-ism, but for the sake of compatibility.  We should
suggest that multi-channel synths don't make a ton of sense in the virtual
world and discourage them.

Also - do we support multiple channels on instruments or any old plugin?

        GMPI must support multi-channel plugins, where each channel has an
        identical parameter and IO structure.  There may be an arbitrary
        number of channels per plugin.


How's that sound?

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