[gmpi] Re: 3.11 topic: Dynamic plugin structure
- From: David Olofson <david@xxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 27 Apr 2004 10:55:44 +0200
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
