Subject: Re: [linux-audio-dev] ladspa plugin GUI proposal
From: Maurizio De Cecco (maurizio_AT_mandrakesoft.com)
Date: Wed May 24 2000 - 20:06:24 EEST
> >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.
Right :->.
> 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.
Not by definition, it is a design choice.. Why you assume a scenario
where the DSP plug-in is the master and have all the knowledge ?
It is the application after all that load (or ask loading) the plug-in,
the same application may decide which GUI module to load, and when.
In other word, the "plug-in" may consists of more than one linkable
entity, and some information may stored in different form that the DSP
plug-in itself.
Also, why are we supposing there is only *one* GUI for a module ?
Take a reverb: it would make perfectly sense, in different
applications, to have *no* UI, or a simplified UI to choose between a
few presets, or a programming GUI; note that there are applications
where it would make absolutely *no* sense to give the user the third
UI.
[Ehm, as you may suppose, here i am talking from the general Linux
developement point of view, not from the point of view of a musicians
that use Linux].
> 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.
It depends on what this information consists of; if this information
*is* in some form graphical (i.e. "i want a 10cm slider") there is no
way i know to solve this problem with a reasonable amount of
developement resources.
If the information is "I have 10 int parameters, here are the names
and the range", this is ok, and possibly needed in the API; a
reflection part of the API, essentially; but, again, it is a design
choice; you may very well assume that the audio plug-in is distributed
with a separate GUI plug-in (for example, a GTK widget) that know
about the structure of the plug-in, and do *not* need to ask.
Anyway, as you say later, this is not the point, because this API exists
already.
> 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.
Personally i think that:
(1) there *may* be host/plugin interaction depending on the application,
and this interaction may be different in different applications.
(2) abstracting away this information is equivalent, conceptually,
to define a small new toolkit, and then to implement it in all the
available toolkit.
Point 2 have a number of interesting consequences:
a- the user interface of the plug in would be distributed with the plugin.
But different applications may require different UI.
b- It would simply be a nightmare to mantains and evolve such a toolkit,
because there would be tens of different implementations.
c- The toolkit must be limited to be sure that can be implemented in all
the toolkits; as a consequence, it risks to be left aside sooner
than expected.
> >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.
Sorry, what i meant here is that IMHO the discussion prove that the
interface cannot be built by the plug-in itself without making a set
of strong architectural and plug-in choice; see below.
> The issue is *who* constructs the visual representation that allows a
> user to control those parameters (ports) ? The plugin ? The host ?
There are two issue here: the first is who *specify* the interface,
the other is who *construct* the interface.
My personal answers are:
- who *construct* the interface: no hope for the plug in;
must be the host.
- who *specify* the interface: the abstract toolkit above would
allow the plug-in to specify the interface, and the host to
build it; personally i think the interface should be specified
by a third entity, the GUI plugin.
> >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.
Sorry, i *was* talking about Linux; there is a very big and growing
interest in Linux as an emdedded system, some of them without an UI,
and some other with an UI that is a toolkit built on top of the
Linux framebuffer device.
Berlin is a new effort for an alternative Window system for Linux.
And finally, if i had to give a concert using Linux for sound
processing, i would prefer to use a separate server machine without
X-window running.
> 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.
True; i am strongly against any solution that would require linking
toolkit or X specific code to the environment where the plug-in run;
but it is true that the plug-in may provide a description of its user
interface in toolkit independent way.
> 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.
OK, as i said below, i fully agree that the API *must* include the
event mechanism needed to implemnt some kind of Observer/Observed
paradigm.
But this have nothing to do with the plug-in knowing its own UI.
> >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.
What's wrong in distributing with your plug-in a Qt and/or a Gtk
interface for it, under the form of a widget ?
Or under the form of a KPart (for KDE) or a Bonobo component (for GNOME) ?
Sure, double work; but vastly better UI, w.r.t. a custom defined and
so limited toolkit.
> 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.
The construction of the GUI is independent; i.e. it is dependent on the
context; the same entity that load the plugin may decide to load or
not load the interface; the plug-in do not necessarly need to know.
The other two points, i.e. changing values, and reacting to changes,
are related to the way the plug-in interact with the rest of the world,
and are not specific to the GUI; it may be an other module, completely
not graphic, for example.
> When and how does a GUI
> pick up the change ? GUI's are event driven - there is no event
> associated with this in LADSPA.
Good; here we agree; a event mechanism that allow to implement
the Observer/Observed paradigm is essential to interface a GUI,
and *any* other modules; it is not a GUI specific problem, and
should be defined w.r.t. the parameter space of the plug in API,
not in reference to the GUI.
> 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.
I would put the problem the other way around: the problem is letting
to the application (and to the plug-in relative GUI) do whatever it wants
with the DSP plug-in.
OK, then my proposal is: left the GUI definition completely away from
the API; and let's works on the API extension needed to work with
(any) GUI, expecially the event part; but let's do it independently of
the application itself.
Then, the abstract toolkit thing is an other matter; to start, why
don't add to the API something like a "plug-in property API", where
the application may retrieve properties of the plug-in ? I am talking
about static properties, not run time properties; properties that can
be accessed without loading the plugin (actually, they can be get
directly from a file, bundled in some way with the plug-in, depending
of the package).
Then, if there is an interest in such an abstract toolkit, can be
developed on top of a reasonable completed API and on top of this
property mechanisms.
But .... : personally, i would suggest to drop completely the abstract
toolkit approach; it has been tried tens and tens of time, last in the
Java AWT, with horrible results, and finally proved to be not
competitive with custom build UI; the mantainance cost is horribly
high, and the result would be very limited, and very time consuming.
On the other side, there is probabily a good reason to develop toolkit
specific libraries to help developing GUI for plugins .. but a separate
entities ...
Better use the human resources to develop new DSP stuff :->
> ps. and yes, i have nothing better to do today than sit and write to LAD:)
Me neither :->
maurizio
-- Maurizio De Cecco MandrakeSoft http://www.mandrakesoft.com/
This archive was generated by hypermail 2b28 : Wed May 24 2000 - 20:36:46 EEST