[gmpi] Re: 3.11 topic: Dynamic plugin structure

On Tuesday 27 April 2004 00.45, Tim Hockin wrote:
> Sorry to be so quiet lately - been digesting and dealing with life.
>
> On Mon, Apr 26, 2004 at 01:15:41PM +1200, Jeff McClintock wrote:
> > AU does it in a very generic way,  the plugin has "Properties",
> > unlike parameters, properties are not automatable.  They're stuff
> > that dosn't change much (plugin name, parameter list etc).
>
> OK, I can deal with this, I think.

These Properties seem to be what I've called "non real time controls" 
in other discussions; ie controls that cannot be automated in any 
useful way, since the plugin may stop working for extended periods of 
time when they're changed. (How that's actually handled in a real 
time host is another matter. I believe we've discussed that before; 
worker threads, worker callbacks and stuff...?)

Anyway, I'm not sure whether it's best to treat them as a different 
type of interface, or just parameters/controls marked "NONREALTIME", 
but the idea seem fine to me.

(In a perfect world, we wouldn't need to deal with operations that 
can't be done in the real time context of a host, but if we assume 
that's the case, we'll just end up with hosts that stall and stutter 
whenever you fiddle with the plugin network, simply because it's too 
much of a PITA to rip plugins out and run them in another thread 
while processing certain parameter changes...)


> A few more questions before final reqs on this, maybe.
>
> 1) Does the host need to give an OK for a plugin to change its own
> parameter list?

What would the plugin do if the host says "no"? Refuse the property 
value that caused the plugin to want to change it's parameter 
list...? And why would the host say "no" in the first place?

I say no. The host will just have to deal with plugins withdrawing and 
adding controls, ports and stuff. Cleaner and simpler than the 
alternatives, I think.


> 2) Can the host change the parameter list?

How would the host know what a valid parameter list looks like, and 
how does it tell the plugin what it wants?

This is where the "modules" approach gets in, and it would have to be 
rather explicit for this to work, I think... I don't really like it 
(more complexity, but still rather limited), but maybe we can't avoid 
it?


> 3) Does the host need to give an OK for a plugin to change its own
> IO config?
>
> 4) Can the host change the IO config?
>
>
> (I know the IO configuration doesn't belong in this section, but
> they seem to be isomorphic, so maybe we can solve them together?)

Yeah, I think the same logic applies to the I/O configuration. (In 
fact, I'd like to think of audio I/Os and controls/parameters as 
pretty much the same thing, although with different data formats.)


> This brings up a few more thoughts.  Firstly, we need to provide a
> state-header or something, which gets saved and restored before the
> parameter values.  Plugins with dynamic structures can put
> something in there to define the structure.  Simple plugins can
> ignore it.

I think that depends on how the plugin structure is controlled. If 
it's done through plain properties, the state is defined by the 
current values of all properties.

However, if we need to support plugins that "mysteriously" change 
their structure, based on out-of-band communication with custom GUIs 
or something (which is an idea I strongly dislike), we'll obviously 
need some way of saving and restoring their state. Whether there has 
to be one state for the controls + I/O configuration and one for 
other stuff (such as the "fingerprint" memory of a noise reduction 
plugin, for example) is another matter...


> Secondly, we probably need a way to group parameters together.  Is
> one level of parameter grouping enough?  Does it need to be
> arbitrarily nested?

I think this depends on the implementation, and/or the rules for 
changing the parameter list. The problem with something like having 
all parameters in a single table where each parameter has an index in 
a contiguous block, is that parameters may move around when you 
change the layout. If parameters are to keep their indices, all you 
can do is add/remove parameters or groups of parameters at the end of 
the table. If we use a tree structure, or just a list where 
parameters are addressed by (per plugin) unique IDs rather than raw 
indices, that problem goes away.

Either way, grouping in itself is IMHO just metadata. Apart from 
dealing with variable size ranges of parameters or parameter blocks, 
there's no need for the low level plugin API to deal with this at 
all.

How about a VFS style parameter naming scheme? Just name parameters 
"lfo/rate", "lfo/depth/", "envelope/attack" etc, so hosts that care 
can tell how they're related.

Now, if the plugin has a variable number of LFOs, just name the 
property that controls the count "lfo.count" or something, so the 
host can tell what it controls, if it cares. (If you're using the 
plugin's custom GUI, it doesn't really matter, because this relation 
would be designed into the GUI anyway.)


> Thirdly, we will still have to solve multi-channel plugins - how do
> you save a single patch vs an entire snapshot of all the channels?

The VFS style naming scheme might work for that too. If you somehow 
mark the nodes that represent channels, hosts that care can just look 
for those hints when the user wants to deal with stuff on a per 
channel basis.


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


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