[gmpi] Re: 3.11 topic: Dynamic plugin structure

Responding to Tim:
On Wed, Apr 28, 2004 at 01:17:27PM -0700, Chris Grigg wrote: 
 Not necessarily, I was thinking you could re-make any of the per-slot
 parameter lists if you need to.

whooh. We are starting to get complex, now..

No, it's just flexible. No complexity unless you specifically want to go there.



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

I disagree that the string format is error prone..

I meant: Nothing prevents the programmer from making a typing error resulting in the 'same' parameter being spelled differently in different channels. If there are param name lists referenced by ptr, then all channels meant to be the same -will- have identical names.


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

Where as with the OSC-naming I would just say:

parameters[] = { "/master/gain" };

Are you saying the dead simple 4-line pattern I showed above, which allows all the flexibility we've been talking about for the universe of GMPI plugs, is too heavy a burden for simple plug writers? That's hard to buy. (Also, no need for the /master part in a 1-chan plug.)


I think that in the end, it will all appear the same to a user. :)

But!!! users will never see the slot address part ( '/master' ) of the param address. Whereas the other parts may or will be displayed in GUI.


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


All this leads to a lot of realloc()s and parallel structures.  It could
all be similarly done with slightly more complex data structs.

Can you illustrate?


> Alternatively you could do something like this...: 

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

...and just change ptrs there.

simpler, and therefore better, IMHO.

Maybe. I'm a sucker for indexed indirections.


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

As compute power goes up, it become more practical to have things in
non-binary form.  The advantage that I see of the strings method is that
it is EASY to look at the list and discern what is going on.  This COULD
be easy too, but string parsing is so easy and so cheap.

Only partly a matter of computing power, it's also a matter of finding the right balance between newbie ease of programming and not cramping the rocket scientists. Anyway, non-binary form makes sense in cases where civilians are going to be looking at the data directly and need to be able to read it. When would a human ever see the whole param address strings? (Debugging doesn't count.) Don't think it happens in real life, at least for the slot part of the address; that'll just be used to put the widget into an appropriate box, i.e. it'll always get stripped anyway.


Further, if we
are going to allow arbitrary grouping of parameters, we'll need to codify
even more substructs.  Or you'll have to parse delimited strings anyway.
:)

Unavoidable under any flavor of parameter addressing -- plugs with dynamic parameter lists will always be responsible for managing those lists. All we can do is spec the framework they use to report their results back to the API.


Really, what is easier to grok - arrays of pointers to arrays of strings
or an array of strings?  We're both encapsulating the same data.  I just
think that a string encoding covers both multi-channels and arbitrarily
nested groups.

Again, using strings for slot addressing is inefficient.


And it's easy to grok. :)

Only if you're looking at the strings, which nobody will be.


> ...It's a reasonable disagreement.

Agree to disagree for now? I'll include both as spec fodder.

Good outcome!

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