[gmpi] Re: 3.11 topic: Dynamic plugin structure
- From: Tim Hockin <thockin@xxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 28 Apr 2004 12:24:08 -0700
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). 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.
I think David's OSC-like model (where toplevel nodes are the class -
master, channel, etc) gives us all the flexibility we could want and makes
life simple for plugins. But again, these are details.
> 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 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.
Strings have advantages of being easy to read by humans and simple to
parse by machines. 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.
> I don't like having different plug types, like VSTi vs. VST fx. All
> GMPI plugs should IMHO have access to the same feature set.
> Simplifies the world for plug and host writers.
I agree totally.
> I agree with David here, and I think that /-delimited parameter names
> within a 1D slot structure (i.e. struct with int channel index +
> string param name not including the channel index) both meets all of
> the other requirements (including index ignorability) and will be on
> balance easier to implement for everyone. Most plugs will be 1-slot,
OK, I will work up a list of reqs from these emails today, if possible.
----------------------------------------------------------------------
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
Other related posts:
