linuxaudio.org

On Wed, Mar 2, 2011 at 2:55 PM, Stefano D'Angelo  wrote:
> Plugins expose "control ports" (which, to me, are a design mistake how

quoted text
> they're done, but whatever) for the purpose of managing how they work.

no different than any other plugin API, except that the concept is a

bit more unified than "data" and "parameters" as found in, say, VST or

AU.
> Since it's stuff for the user, they should be effective and

quoted text
> understandable for the user. And here's the first problem: parameters

> and GUIs don't necessarily have to match! E.g., my amp simulator

> algorithm should really expose stuff like "air impedance" or "triode's

> magnetic perveance", that's stuff the "average user" ("dumb" guitar

> player) doesn't understand. I would prefer to show "air temperature"

> and "triode model" instead.

AU, which is the only other plugin API to explicitly support

plugin<->GUI separation (even across processes) works in exactly the

same way as LV2. there are many AU plugins which do precisely what you

describe, yet still use a host-mediated parameter accessor API to both

control and represent current plugin state. this conceptual issue has

been thrashed out many times on the coreaudio mailing list as far back

as 1994, and nobody ever convinced the coreaudio guys (who are a smart

bunch of guys) that they had done it wrong.
the principle remains: access to plugin parameters is mediated via the

host to facilitate several things that would be impossible to do

properly, if at all, if they instead happened directly.

meta-parameters are used to provide the kind of thing you're

describing, and the "real" parameters are marked as "not for display"

in the (unlikely) event that the host creates the GUI for the plugin.

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev