Re: [linux-audio-dev] ladspa plugin GUI proposal

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed May 24 2000 - 18:51:15 EEST


In message <lgg0r86kgy.fsf_AT_ewok.mandrakesoft.com>you write:
>
>Paul Barton-Davis <pbd_AT_Op.Net> writes:
>
>> So, back to the drawing board. Either we have to provide the toolkit
>> layer (like the vstGUI library), or we specify the host's chosen
>> toolkit and have the plugin be required to use it. This last one is
>> pretty disgusting.
>
>I still don't understand why the plugin specification should include
>anything about the GUI.

Well, thats part of the discussion we need to have.

If there needs to be interaction between the host and the plugin in
order to create a GUI, then some information has to be exchanged
between them to get this to work, by definition. If that information
can be passed in a way that is independent of any particular
assumptions about the way the GUI is going to be implemented, then it
makes sense to me to incorporate it as part of the overall
specification of the plugin. By contrast, if there is either no
interaction between the plugin and the host w.r.t. the GUI, or the
interaction requires very specific information, then I agree that its
not really appropriate for it to be part of the plugin specification.

It should be clear that I think that (1) there *must* be host/plugin
interaction w.r.t the GUI and (2) the information required is minimal
and can be abstracted away from the particulars of toolkits etc.

>As the discussion prove, there is practically no way to do it so it
>would work with all the potential applications.

We haven't proven anything yet.

>It is a good design practice to separate UI from applicative code; why
>don't specify an API to access and potentially discover which
>parameters the plugin have to offer, and leave the UI and plug in problem
>separate ?

We already have an API to discover which parameters exist. Thats not
the isssue.

The issue is *who* constructs the visual representation that allows a
user to control those parameters (ports) ? The plugin ? The host ?

>The plugin may very well run in an environment *without* X windows
>(either an embedded audio application, or an audio processing server,
>for example); or it may run in an environment where the user inteface
>is *not* X Windows (framebuffer based toolkits, Berlin, whatever).

LADSPA stands for *LINUX* Audio Development Simple Plugin
Architecture. There are other good plugin API's for BeOS (VST, for
example). LADSPA has never been an attempt to define a cross-platform
API, even though it would work as one right now.

Nothing that I've proposed would make it unusable on a non-X platform,
and I specifically pointed out that a plugin should not expect that
its "gui_constructor()" function will be called. A host is free to
ignore the plugins wishes in this area, and build its own GUI.

>The plugin may be usefull in an architecture where the processing and
>the interface run on different memory space, or may be linked together;
>and so on and so on ...

The different memory space is an issue. Once you allow too big of a
latency between the GUI and the actual plugin run() and run_adding()
thread, the GUI becomes useless for real-time work.

So, yes, I agree that it would be wise to design something where the
GUI cannot just do absolutely direct manipulation of the plugin's
variables.

>My impression is that a plug-in API should be just that, a plug-in API,
>while forcing in the UI will put a severe number of constraints on
>the application itself.

My goal is precisely *NOT* to force in the UI. I want to provide a
hook where the host can say: "OK plugin, here's your chance to create
a GUI. Do it now, or forever hold your breath". That's all.

Well, not all. Because you are *COMPLETELY* ignoring automation, which
is an important component of all high-end apps, and cannot be done
without cooperation between the host and the GUI, and inevitably
involves the plugin.

>plug-in are a different things, that depends on many things the
>plug-in itself could not care less, like the use of GNOME or KDE.

But the plugin MAY care! Go take a look at jezar's freeverb web page
mentioned here yesterday. Check the (VST?) GUI. To me, it looks very
cool. Nothing that exists in LADSPA today would allow it to have
anything like this appearance.

>If we have a GUI-free API for the plugin, we can later define
>API for graphical plug in (or more safely use the already existing
>standards) for defining the plug in part of the UI architecture.

I agree that the existence of a LADSPA-specific GUI toolkit is
independent of the plugin spec. But the point at which the GUI is
constructed, the way that the GUI alters port values in the plugin,
the way that the GUI reflects changes in the plugin port values
(automation, port connections from other plugins): these are not
independent, as far as I can see, from the basic operation of a
plugin.

Suppose that a plugin wants to show the sample rate value associated
with a particular (input) port. Suppose that another plugin is
connected to that port, and changes its value. When and how does a GUI
pick up the change ? GUI's are event driven - there is no event
associated with this in LADSPA. Having GUI's poll their plugins is
expensive, and stupid. So there is a problem here as well.
           
           gtk_timeout_add (200, poll_plugin, this_plugin) - GACK!

>Sure, if you want to use a plug-in in a given graphical environment
>you will be forced to develop a UI for that graphical environment;
>this is true for *any* software developement today, don't try to solve
>a problem that 30 years of GUI developement have not solved yet !

This is not the issue, again. I'm not trying to figure out how to
build a UI for a given graphical environment. I'm trying to figure out
how to let the plugin do whatever it wants with a GUI (including
asking the host to take care of it), and have that work correctly.

--p

ps. and yes, i have nothing better to do today than sit and write to LAD:)


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Wed May 24 2000 - 19:29:51 EEST