Couple more side-comments:
David wrote to Tim:
> > 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.
...>> > 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.)
numChannels = 3; // Host queries this first channelParamNamesLists[] = [0,1,1,1,-1] // Host queries this second
masterParamNames = { "volume", "pan" }; synthChanParamNames = { "shape", "octave" };
... [...]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 wewould 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 ofsense 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 oldplugin?
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 anidentical 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.
---------------------------------------------------------------------- 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