[gmpi] Re: 3.11 topic: Dynamic plugin structure

Responding to Tim --

Glad you see, in the end, some amount of value here; let me see if by clarifying a few points I can show more of it...

On Wed, Apr 28, 2004 at 10:53:26AM -0700, Chris Grigg wrote:
 > 1D indexing makes it possible to orthogonalize your plug's param name

 lists, so you just keep one copy for each slot type and reference it
 for each slot instance -- that's easier than rebuilding the whole
 param names list at every reconfig and inserting index strings.  And
 still permits completely dynamic param lists for plug authors that
 want to go that way.


It means that you have to statically define the list of available
modules/slots (or at least, statically per-instance).

Not necessarily, I was thinking you could re-make any of the per-slot parameter lists if you need to.


This has the
advantage of exposing to the host the various modules/slots that can be
loaded.  But is that really an advantage?

Hm, I don't think it does that so much. Though there might need to be a way to expose that, if (and only if) modules need to be configurable from a host-driven way. Not sure this is needed, as it seems reasonable for a modular plug to depend on having a custom GUI.


Module structure is not something that will be changing a lot.  I think
it's a mistake to worry about performance or anything.  It's marginally
easier than a truly dynamic parameter list to visualize, but marginally
more complex from a simple-plugin point of view.

Hm, not sure I agree it's more complex. It's certainly less error-prone.


Why should my simple amp plugin need to define a module which then has to
be instantiated.

No no, much simpler than that. No actual modules or instantiation, those are abstractions. It can all be done in data:

// Parameter Names for simple Gain plug

numChannels = 1; // This plug has just one channel.
channelParamNamesLists[] = { 0 } ; // It always uses ParamNamesLists[ 0 ] ...
ParamNamesLists[] = { &masterParamNames }; // ...which always points at masterParamNames[]...
masterParamNames[] = { "gain" }; // ...which always has just one parameter, gain.

Finito.



> Also, with 1D indexing you could say index 0 corresponds to 'master' 
 and do away with the whole 'master/' and 'channel[n]/' things --
 needless string conversions.


Well, the strings are partly for humans.  The cost of parsing is low and
infrequent.  But there is no problem with your change either.  MIDI starts
at 1 anyway, right? :)

Depends how you count. ;-) I'm partial to 1-16 myself.


> numChannels = 3; // Host queries this first
channelParamNamesLists[] = [0,1,1,1,-1] // Host queries this second

ParamNamesLists = { &masterParamNames, &synthChanParamNames] }

 > masterParamNames = { "volume", "pan" };
 > synthChanParamNames = { "shape", "octave" };

I don't get what channelParamNamesLists is about, but it doesn't really
matter.  This is the same as my original proposal, but encoded in a binary
struct instead of strings.

That's probably because I was very sloppy in the example. channelParamNamesLists has one entry per plug slot, and each entry is the index (in paramNamesLists[]) where that slot's parameter name list can be found. The -1 just is a bad idea signalling the end of the array.

So { 0, 1, 1, 1 } means:
        slot 0 uses masterParamNames,
        slot 1 uses synthChanParamNames,
        slot 2 uses synthChanParamNames,
        slot 3 uses synthChanParamNames

To change the parameter list for a channel, you put the parameter names into a string array, put a pointer to the string array in paramNamesList[] (this is what allows one param list to be used in more than one chan), and put the corresponding index into channelParamNamesLists[ channelYouChanged ]. Plugs with dynamic parameter lists will need to do this dynamically, but plugs with static parameter lists (most plugs) will define the data in source code as shown, and never have to change it.

Alternatively you could do something like this...:

    channelParamNamesList[] =
        { &masterParamNames,  &synthChanParamNames,
          &synthChanParamNames,  &synthChanParamNames };

...and just change ptrs there.


Also OSC compat is probably good.

Huh. OSC compat seems to me almost 100% irrelevant. But I would still like to look at the OSC parameter name spec, can't anyone provide a URI?


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

 You can still ignore the index if it's a separate int in a struct,
 nothing about doing it in the string makes this any easier -- in
 fact, it makes it a lot harder because you have to parse the string
 and convert, yuk.


Come on, now.  String parsing is trivial.  I can write you a parser to
build a tree of these / delimited nodes in about 1 hour.  This parser gets
written once in the host SDK and never again.

Just because it's simple doesn't mean it's not crufty. 8-) It's a question of whether the convenience of having it all in a single string outweighs the burden of: Stripping/adding channel info at connection time and reconfig time; dynamically rebuilding parameter lists on the fly at reconfig time; risk of error in manually typed multichan param lists; complicating parameter naming for very simple plugs. Looks to me like the scale tips one way, you're saying it looks the other way to you. It's a reasonable disagreement.

best,

-- Chris G.

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