[gmpi] Re: 3.11 topic: Dynamic plugin structure

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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: