[gmpi] Re: 3.11 topic: Dynamic plugin structure

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

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

I disagree that the string format is error prone..

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

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

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

> Alternatively you could do something like this...:
> 
>     channelParamNamesList[] =
>       { &masterParamNames,  &synthChanParamNames,
>         &synthChanParamNames,  &synthChanParamNames };
> 
> ...and just change ptrs there.

simpler, and therefore better, IMHO.

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

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.  And it's easy to grok. :)

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

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

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