On Wed, 2011-03-02 at 15:08 -0500, Paul Davis wrote:
> On Wed, Mar 2, 2011 at 2:55 PM, Stefano D'Angelo <zanga.mail@email-addr-hidden> wrote:
>
> > Plugins expose "control ports" (which, to me, are a design mistake how
> > 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.
There will be a Death To Control Ports initiative at some point. LADSPA
control ports suck.
It turns out there is a more meaningful semantic dichotomy of ports.
Something like:
* "Value" ports are simply values of any type, inherently timeless
* "Signal" ports are /consumed/ and time dependent
The big thing that leads you to this is the realisation that it makes
perfect sense to have the exact same data type in either kind of port
(e.g. you can have a float value, or send a float message, and the
semantics of how the plugin interprets that are very different. If "1.6"
seems crazy as a message, consider Max/MSP). Data type is not the
fundamental difference(*).
The other thing is that this becomes essentially mandatory when you have
multiple contexts per plugin.
Stay tuned...
(As for control ports, they should be, and will be, events 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.
Yep. There is no question that this is the way to go. Bunch of useful
things are possible that wouldn't be otherwise... QED.
-dr
(* It took a lot of trial and error and failed attempts at extensions to
figure this one out, it may not be intuitive right away?)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Thu Mar 3 00:15:04 2011
This archive was generated by hypermail 2.1.8 : Thu Mar 03 2011 - 00:15:04 EET