Subject: [linux-audio-dev] Re: LADSPA GUI [was: New LADSPA Version - Issues Resolved?]
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: to maalis 09 2000 - 19:48:30 EST
>I didn't mean to include any GUI functionality into the plugins. I was
>just trying to imagine how I could include LADSPA support into
>terminatorX (as I just implemented a sequecer that uses events that
>support only one float value - which fits nicely to the LADSPA design
>;). Now I think for your usual DSP plugin the author doesn't really want
>to take care of GUI issues, I guess.
Well, we perhaps need 2 different versions of "plugin".
In the Windows/Mac audio world, a "plugin" almost always come with a
GUI front end to allow it to be controlled. In the Windows/Mac worlds,
the plugin writer specifies not just port parameters, but the layout
of the GUI. In some combination of a distaste for existing GUI "look
and feel" and/or a need for more precise control, the host GUI API has
gotten more and more sophisticated, to the point of being not far from
a moderately-capable GUI toolkit.
I took this approach with Quasimodo, and in that case, the "host"
implements the GUI using an XML-specification of its components and
layout. I have found that to be a less-than-ideal situation, because
various Quasimodules need specialized UI components that they would be
better off implementing themselves.
The "plugin" you are talking about is much simpler (common in the
Linux world, where focus on "ease of use" issues is low, and focus on
"power, flexibility and novelty" is high). Its really just an
algorithm implemented with a wrapper around it.
> For better integration I think it
>makes sense when the host takes care of the GUI (in any way). The
>problem is: Let's say my host (with a GUI ;) has LADSPA support and I
>load a plugin and let the user place it somewhere in the audio
>processing chain - now how can he operate it, how can he modify
>parameters/ports?
Right - this is exactly the problem. LADSPA itself offers no support
for this whatsoever, but assumes that the plugin will take care of it
*somehow*.
I would like to avoid having each host applicaton support its own
"mini toolkit". One way to do this is to require plugin writers to
implement a GUI for themselves, using a separate library if need
be. The problem with this is the choice of toolkits. We don't want to
tie LADSPA (or MuCos) to a particular toolkit, so I am unsure about
the best path.
Ultimately, it really comes down to what you mean by a plugin. In the
ALSA library, plugins really are just algorithms with few or no
parameters (e.g convert X bit samples to Y bits using a specified
algorithm). This kind of plugin doesn't need a GUI. At the other end
are things like Antares AutoTune, which requires a fairly complex and
sophisticated GUI to use, and would be useless without that level of
GUI presentation.
Anybody have any insights ? I know that if we just required the use of
GTK, it would be easy, but thats not going to make many people happy ;)
--p
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST