On Tue, 2012-02-14 at 12:52 +0100, Nick Lanham wrote:
[...]
> The other thing I'd love to be able to do is somehow change the # of
> control ports dynamically (so I can expose exactly the right # of
> gain/pan ports for the # of samples). dynamic-manifest seems like a
> promising way to do this, but I haven't seen a way to ask the host to
> re-poll for a new manifest, so that makes it pretty much useless if you
> ever want to change kits. Any thoughts on this?
Too many thoughts, as usual :)
Right, dynmanifest can't really do things like this for an instantiated
plugins, it's only a discovery time thing.
There are two ways to go about getting this: "dynamic ports" and doing
all control via messages (so we don't need a port for every control).
Dynamic ports we don't really have yet. There is dynparam, but this is
not widely supported. I don't particularly like it because it's not
very extensible, doesn't really mesh with the RDF data, adds too much
API, and has some other issues; but these mainly stem from it pre-dating
a lot of needed extensions and established best practises. Something
similar to / based on it with a more modern take could be alright.
That said... I am increasingly becoming convinced that ports are
particularly awful for control (if not everything). Among other
problems, they are too static, which is your problem. Doing everything
via messages (e.g. "set gain to 1.6") that all travel in/out one
designated port (as events) keeps things completely dynamic, and breaks
free of the whole "single float per run()" thing so we could have
time-stamped control ramps and such.
The actual data types, logistics, etc. of this are being hammered out as
we speak, but mainly intended for "load this file" type uses (i.e.
things we can't do at all, currently). Nothing yet for using it for
control parameters, basically what needs figuring out there is how to
describe controls, add/remove them, announce new ones, etc. I will
consider making another example plugin that tinkers with this stuff.
The real win of a message-based approach is that *everything* happens
via meaningful events (which travel via ports), which means it's all
serialisable and network transparent and all that - including creating
and/or inspecting new parameters. This means UIs can do it. This is
not true of an API-based approach like dynparams. In general I think it
is an extremely bad idea to have UI<->plugin or plugin<->plugin
communication limited by explicit host support; it holds everything
back.
If anyone has an ideas for a very simple (no samples and threads and
such) example plugin with a reasonable use for multiple parameters, do
tell. I thought a multi-point envelope would be a neat one, but there's
too much UI work there.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Wed Feb 15 00:15:01 2012
This archive was generated by hypermail 2.1.8 : Wed Feb 15 2012 - 00:15:02 EET