[LAD] Portable user interfaces for LV2 plugins

[Stefano D'Angelo]

2011/3/2 Paul Davis <paul at linuxaudiosystems.com>:
> On Wed, Mar 2, 2011 at 5:36 PM, Stefano D'Angelo <zanga.mail at gmail.com> wrote:
>> Since I'm not just complaining or posing hypotetical questions, but
>> want the understand the issue at its deepest, I want to ask you to
>> please better point out what is exactly this host-mediate parameter
>> accessor API (a link to docs is more than enough).
>
> the AU model is subtly different in that it uses a
> listener/notification model. a view can directly set a parameter, but
> doing so will notify zero or more "listeners" of the change. these
> listeners include the host, which wants to do automation (often) since
> this is not a feature of the plugin(s).
>
> and i'll be fair, the AU model includes "custom properties":
>
>   "Host applications can query an audio unit about its parameters and
> about its standard properties, but not
> about its custom properties. Custom properties are for communication
> between an audio unit and a custom
> view designed in concert with the audio unit."
>
>   http://developer.apple.com/library/mac/documentation/MusicAudio/Conceptual/AudioUnitProgrammingGuide/AudioUnitProgrammingGuide.pdf

Ok, now I know what we're talking about. This kind of stuff looks to
me as stuff that is generally specified in the RDF data in the LV2
model (at least the basic standard properties), or am I missing
something?

> on re-reading this, i'm not sure i want to hold this up as a the best
> model for LV2, but at some deeper level it is because buried somewhere
> in all that kRuftilyNamedVerbosity is an API that permits
> process-level separation of the GUI (view) and plugin.

May I ask you what does it allow to you to do that you like, specifically?