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 namelists, 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).
This has the advantage of exposing to the host the various modules/slots that can be loaded. But is that really an advantage?
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.
Why should my simple amp plugin need to define a module which then has to be instantiated.
> 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? :)
> numChannels = 3; // Host queries this firstchannelParamNamesLists[] = [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.
So { 0, 1, 1, 1 } means: slot 0 uses masterParamNames, slot 1 uses synthChanParamNames, slot 2 uses synthChanParamNames, slot 3 uses synthChanParamNames
channelParamNamesList[] = { &masterParamNames, &synthChanParamNames, &synthChanParamNames, &synthChanParamNames };
Also OSC compat is probably good.
> >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.
---------------------------------------------------------------------- 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