[linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)

[Chris Cannam]

On Tuesday 08 Jun 2004 6:59 pm, Tim Orford wrote:
> is it possible to summarise the objections to the dssi approach
> for ladspa?

One objection is that it completely avoids addressing the problem of 
how to embed the GUI inside the host on-screen.  Each GUI is 
basically assumed to run up as a separate top-level window.

I could imagine some library support for re-parenting GUIs, but it 
certainly isn't intrinsic to the current proposal.  The problem is 
exacerbated by the fact that GUIs that are most comfortable running 
in entirely separate windows are likely to be the more complex ones 
that are perhaps less amenable to being hosted plugins in the first 
place -- if the GUI can happily run standalone, there's a stronger 
argument for making the entire "plugin" a standalone JACK app. 

(The upside of this, of course, is that if the GUI crashes it won't 
bring down the host.  Since the GUI is often the most unstable bit of 
a plugin, that could be a very good thing.)

A further conceptual criticism is that it will just encourage people 
to produce GUIs that are inconsistent, inelegant, tasteless and hard 
to use -- i.e. it doesn't do anything to address the biggest problems 
a plugin author might face when writing a GUI, namely what to build 
the GUI from and how to design and organise it.  A separate library 
to help with that by wrapping basic toolkit widgets in forms likely 
to be of use to audio plugins might be worth considering.

An implementation disadvantage is the need to produce two separate 
object files (the .so and the GUI), to ensure that they can both be 
discovered by the host, and to keep them in sync -- for example to 
make sure the GUI knows about the most up-to-date set of plugin 
ports.  Of course the GUI can always load the plugin and query it 
itself, but most probably wouldn't want to do that.


Chris