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