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 [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
