[gmpi] Re: 3.11 topic: Dynamic plugin structure
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 28 Apr 2004 16:15:02 +0200
On Wednesday 28 April 2004 10.22, Tim Hockin wrote:
[...]
> I think pure indices is a bad idea. I think symbolic names is a
> good answer.
Yeah; symbolic names that are turned into some form of "parameter
address" object by the plugin's connect() method, I think. (See my
last post on Multitimbrality etc.)
> > 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.
Yes, sounds ok.
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.
> > > 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".
Right, but once you have a way of expressing the grouping, it's
trivial to associate metadata and stuff with groups...
> > > 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.
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.)
> 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",
};
?
(NAME '[' INUM ']' means the node is item INUM in array NAME.)
A simple plugin could be hardwired this way, so hosts that care really
understand that there are three channels. A host that doesn't care
about channels can just ignore the '[' INUM ']' stuff and think of
everything as plain parameter names.
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.
Saving the state of the whole plugin means "save everything". Saving
channel N is saving everything that matches "channel\[1\]/".
[...]
> This means that every 'channel' must have the same parameter-list,
> but I *think* this is OK. Am I correct or mistaken?
Not sure... I can see the motivation for keeping it at that level, but
the restriction makes me a bit nervous.
> It means we
> would be codifying a MIDI-ism, but for the sake of compatibility.
Does it really help in any significant way? We still have to use
connect() to hook the "MIDI" event source up to the parameters, so as
long as we can index by channels on that level, we should be fine,
right?
> We should suggest that multi-channel synths don't make a ton of
> sense in the virtual world and discourage them.
Yes... But hey! Then the whole idea of channels is basically a legacy
hack. I think that's another argument for using "channel[N]/...",
since it allows both hosts and plugins to completely ignore the thing
at will, and still have them work together.
> Also - do we support multiple channels on instruments or any old
> plugin?
For easier porting...? Well, yes, they could just (ab)use the same
indexing notation, I guess. Even if hosts in general would only care
about stuff that's hinted as MIDI channels and MIDI CCs, the notation
makes sense to users and any hosts that organize parameters in trees
according to the OSC style names. A host could keep nodes with the
same base name but different indices together (in automatically
generated GUIs or whatever), or just treat them like unrelated nodes
with unique names.
> 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.
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.
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
--- http://olofson.net --- http://www.reologica.se ---
----------------------------------------------------------------------
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:
