Subject: RE: [linux-audio-dev] Re: LADSPA GUI [was: New LADSPA Version - Issues Resolved?]
From: Lars Thomas Denstad (larsde_AT_telepost.com)
Date: to maalis 09 2000 - 20:55:54 EST
Hey, I'm new to the list, and have been previously working on a similar
project in C/C++ (I have some sources online, but I guess you're pretty fed
up with reading other people's source by now), which I had to abandon
because of lack of time back then.
I'm currently following this project and the GLAME project and trying to get
closer every day to the point where I can actually participate in the
coding.
In the discussion about where to implement the GUI, I think you have some
good points. For my project, I intended to make an XML-description of the
user interface, and try to encourage plugin-writers to not use system
functions to the degree that it was possible.
My design would implement the following structure:
HOST APPLICATION
^ |
| | Communicated by static or dynamic linking (at loadtime)
| V
PLUGIN NETWORK
^ |
| | Communication using runtime dynamic linking.
| V
PLUGINS
This seems to be similar to the way LADSPA and GLAME both are going to turn
out, and that makes me happy.
I haven't really looked at the LADSPA project in detail, but I assume that
the plugins will or already have the ability to communicate which ports it
has and which portranges.
When it comes to the GUI-part of it, I have been thinking about the
possibility to add the GUI code in separate .so-files. This will give you a
lot of good options:
If there is no .so-frontend, the host application can make a gui by itself,
that basically just reflects the in and out-ports (parameters and data
streams), and the ranges on each of the ports. This will allow the user to
set all the parameters as he want.
If there is an .xml-frontend, the hostapplication has the ability to make a
"link" between a plugin.so and an .xml-frontend, using the xml-description
to draw the graphics.
For plugins that need or could benefit from more control, like a 3D mixing
application, you can supply a .so-file which holds actual GUI code, and make
the link from the .so-file holding the plugin-code to the .so-file holding
the GUI-code.
Other obvious pros of taking this kind of approach are: You can have
multiple frontends to the same plugin, one using GTK+ and one using Qt if
you must. You can also in .so-files have frontends that takes special care
when it comes to linking in to the host-application.
You will also be in the beautiful situation as an effect coder that you know
you never actually HAVE to care about a frontend, the HOST-application will
have enought to make a simple one from the parameter-information you expose.
(Buzz does it like this, I think, check out http://www.buzz2.com (for
windows) if you haven't already).
Also, the actual effect-plugins (.so) will be binary compatible between
Linux i386, Windows (using Cross-elf, an LGPL loader) and BeOS on Intel. Are
we getting ahead of VST yet?
To sum up, I would like to see the HOST application being able to render a
GUI based on three things:
1) A generic frontend based on the information the plugin exposes.
2) A simplistic frontend based on knobs and dials (and graphics, of course)
based on an XML-description.
3) A binary-module which actually implements GUI code.
If you already have plugin-writers exposing parameter/port-information,
would it be too much to ask to also have it tell the host whether or not it
relies on any platform-native functions?
Thanks for your time!
Yours in Elvis Costello,
Lars Thomas Denstad
> -----Original Message-----
> From: owner-linux-audio-dev_AT_ginette.musique.umontreal.ca
> [mailto:owner-linux-audio-dev_AT_ginette.musique.umontreal.ca]On Behalf Of
> Paul Barton-Davis
> Sent: Thursday, March 09, 2000 4:49 PM
> To: linux-audio-dev_AT_ginette.musique.umontreal.ca
> Subject: [linux-audio-dev] Re: LADSPA GUI [was: New LADSPA Version -
> Issues Resolved?]
>
>
> >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