Re: [LAD] Portable user interfaces for LV2 plugins

From: David Robillard <d@email-addr-hidden>
Date: Fri Mar 04 2011 - 21:51:56 EET

On Fri, 2011-03-04 at 15:24 +0100, Olivier Guilyardi wrote:
> On 03/04/2011 01:53 PM, Stefano D'Angelo wrote:
> > Hence, in this case, I think we should exploit the
> > extensibility/decentralization of LV2: those who, like me, care about
> > "control rate" visualization hints may want to help on web UIs, for
> > example, the others might do the same with native GL.
> >
> > The only thing that we all need to ensure is that things work well
> > together, whatever the host/plugin author choice is, also trying to
> > make the whole thing as painless as it can be for everybody.
> >
> > Side note: this is yet another case where we could proceed to some
> > structured effort coordination at this point, but my feeling is that
> > this won't happen and the discussion will lead nowhere in the end.
>
> There is one thing which stays on my mind.
>
> I am familiar with developing JACK clients, not plugins. However, there has been
> quite a few discussions in the past where JACK was advocated as a way to create
> modules, DSP units dedicated to a specific task. In other terms: some kind of
> plugins.
>
> And what is absolutely nice about this is how it is non-intrusive. When working
> on a JACK client, there are only audio input and output ports, a thin transport
> layer, done. From these primitives, upon this bare but solid ground, a developer
> creativity enjoys a lot of freedom.
>
> However, there's been this critical and long-lasting session handling problem.
> Fortunately, this problem doesn't occur for LADSPA and LV2 plugins, since saving
> and restoring state is performed by the host.
>
> But, with this UI/engine separation, whenever a developer comes out with an
> innovative idea that he really likes, he's very likely to hit a wall because of
> a specific LV2 technical constraint. And at the same time it takes an incredible
> (if only possible) coordination effort to maintain LV2 to fulfill and
> *anticipate* all needs.
>
> But LV2 is extensible. So what I think is that in addition to the extensions
> which imply UI/engine separation (and I understand that it's important in many
> cases), there should be a DoWhatTheFuckYouWantInYourPlugin extension ;)
>
> With such plugins, restoring/saving state would rely on passing a blob in
> addition to restoring/saving the control ports values. There would be no such
> thing as UI/engine separation. The plugin would be self contained. And hopefully
> it would integrate nicely with other extensions such as midi.
>
> I think that this extension, since it would only imply simple but powerful
> primitives, would give a lot of freedom to developers who want that, and at the
> same time be rather easy to maintain.

You are mish-mashing way too many ideas into a big messy ball here for
me to address individually.

However, there is an extension a UI can use to get a pointer to a plugin
instance, which is mostly what you are talking about:

http://lv2plug.in/ns/ext/instance-access/

I do not recommend its use for any situation except where it is
absolutely necessary. Its role is either:

1) Temporary kludge used for necessary plugin <=> UI communication

2) A way to get direct access to waveform data for visualisation or
whatever, with graceful degradation where this is not possible

Use 1 is a big red flag that says something is missing and/or broken.
Use 2 is all good.

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat Mar 5 00:15:06 2011

This archive was generated by hypermail 2.1.8 : Sat Mar 05 2011 - 00:15:06 EET