Subject: Re: [linux-audio-dev] Ladspa Gui's (Is ladspa actually la-dsp-a?)
From: Tim Orford (tim_AT_orford.org)
Date: Wed Jun 09 2004 - 13:58:21 EEST
thanks for your good answer, Chris!
at the risk of repeating old discussions here are some uninformed comments:
On Tue, Jun 08, 2004 at 08:26:21PM +0100, Chris Cannam 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.
thereby remaining flexible and avoiding some extremely thorny issues
over differing toolkits and x event loops.
sure it would be nice to have the embedding option, but in
how many situations is that really neccesary? (Especially as
the gui is optional anyway)
and given that we have an unknown quantity of windows of varying
size, i cant see how that would work. But I personally have no user
experience of embedded plugin windows.
(I think galan does this, but i cant compile it)
> 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.
surely standalones and plugins both have their place? I dont buy
the argument that complex fx should be standalones.
> A further conceptual criticism is that it will just encourage people
> to produce GUIs that are inconsistent, inelegant, tasteless and hard
yes giving people freedom will cause "inconsistent, inelegant, tasteless
and hard to use" things to arise but it will also cause good things
too:-) As long as the gui's are optional, this surely cannot be a
problem. I'm also assuming that multiple alternative gui's can be made
available.
> 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.
not from my point of view. Any special library is going to be very
limiting. I would hate to see linux hobbled by this in the same way as
vst is. I dont think anyone has mentioned in this thread that
presumably libvstgui is a significant factor in encouraging the use of
those cheesy bitmaps that most of us find unusable even if we can stomach
the looks.
and i dont think the plugin author should _have_ to worry about guis
at all. People who can do dsp code _and_ user interfaces are the
exception rather than the rule.
i would rather some ladspa template gui apps were made which encouraged
artists to use whatever tech they wanted. Eg Gtk, Qt, Svg, Flash,
GnomeCanvas, SDL, XUL, DHtml, OpenGl etc...
> 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.
cheers
-- Tim Orford
This archive was generated by hypermail 2b28 : Wed Jun 09 2004 - 14:00:24 EEST