[gmpi] Re: 3.11 topic: Dynamic plugin structure

On Wednesday 28 April 2004 19.53, Chris Grigg wrote:
[...]
> >Provided the parameter list of a plugin includes the full name of
> > each parameter, a simple host can just treat the list as a plain
> > 1D list of unique parameter names. When the user wants to make a
> > connection (after picking a parameter from the long, messy and
> > generally annoying 1D list ;-), just grab the string and pass it
> > to the connect() method.
>
> This works just as well if there's a separate slot index int kept
> with the param name string, and it's simpler to parse.  If it's a
> struct, it's just as easy to pass as a string is.

Yes, that's a good point. I'm beginning to really rather like the 
"hardwired" 1D indexing variant, assuming it really does meet the 
requirements.


> >>  > > And do we codify MIDI-like channels?
> >>  >
> >>  > Optional hints, maybe? Plugins that care should mark the root
> >>  > node of each "channel", and hint controls with their MIDI CC
> >>  > equivalents where applicable.
> >>
> >>  If we codify the 'channel' concept, then any plugin can have
> >> any number of channels.  One of the properties is 'num_channels'
> >> and the host must save the state for each channel.
> >
> >Yeah, but it's only 1D, which IMHO, makes the whole OSC style
> >addressing thing a lot less useful. Will 1D (channel) indexing
> > make everyone happy? Does it really make anything easier? (What
> > about plugins that don't have channels at all? Would be kewl if
> > they could just ignore the whole thing.)
>
> I would suggest it's a mistake to see channel-based internal
> organization primarily as a MIDI thing.  Yes, MIDI has a
> channel-oriented message structure, but mixers have the same
> structure.

I was rather thinking the other way around; *more* dimensions, not 
fewer. How about module/group/subgroup/channel/unit? ;-)


> Many synths have the same structure.  Some effect
> processors have the same structure.  You see it everywhere in music
> technology.

Yes... (You do mean arrays of identical or similar "blocks"; not just 
the hierarchy bit?)


> Saving state per channel shouldn't be necessary if the plug
> provides an overall save state API.

But then how do you save just a single patch, or load a patch into a 
single channel? Even for a single channel synth, it can make sense to 
treat pathes, FX routing and maybe other thing, as separate entities.


[...]
> Yeah, OK, but, why not the much plainer?:
>
> 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" };

Looks great. :-)


> All that /-fu for channel indexing and slot type specification is
> unnecessary and just needs to get unpacked later.

Yeah, it's quite pointless as long as only one level of 1D indexing is 
needed anyway...


> (Though if the
> plug needed/wanted to, it could go nuts with /-grouping within each
> slot-specific param names array.)
>
> Minor point: There's more room for transcription errors in the one
> big literal string table you suggest, whereas this approach
> actually enforces the plug structure in the param names table.

Yeah, another good point.


[...]
> >> It means we
> >>  would be codifying a MIDI-ism, but for the sake of
> >> compatibility.
> >
> >Does it really help in any significant way? We still have to use
> >connect() to hook the "MIDI" event source up to the parameters, so
> > as long as we can index by channels on that level, we should be
> > fine, right?
>
> Again, I would encourage seeing this in other terms besides MIDI.

Well, yes, but that's sort of what I meant. The "codifying a MIDI-ism, 
but for the sake of compatibility" part made me a bit nervous 
there. ;-)


[...]
> >For easier porting...? Well, yes, they could just (ab)use the same
> >indexing notation, I guess. Even if hosts in general would only
> > care about stuff that's hinted as MIDI channels and MIDI CCs, the
> > notation makes sense to users and any hosts that organize
> > parameters in trees according to the OSC style names. A host
> > could keep nodes with the same base name but different indices
> > together (in automatically generated GUIs or whatever), or just
> > treat them like unrelated nodes with unique names.
>
> 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.

Of course. I'm just talking about features; not plugin types 
explicitly defined by the API.


//David Olofson - Programmer, Composer, Open Source Advocate

.- Audiality -----------------------------------------------.
|  Free/Open Source audio engine for games and multimedia.  |
| MIDI, modular synthesis, real time effects, scripting,... |
`-----------------------------------> http://audiality.org -'
   --- http://olofson.net --- http://www.reologica.se ---


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