[LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Mon, 2011-02-21 at 22:53 +0000, Rui Nuno Capela wrote:
> On 02/21/2011 08:32 PM, Paul Davis wrote:
> > On Mon, Feb 21, 2011 at 3:27 PM, Rui Nuno Capela <rncbc at rncbc.org> wrote:
> > 
> >> alas, for some reason, calf and linuxdsp are using it and with great
> >> success. should i say more? maybe not.
> > 
> > well, yes and no. notice that its not possible to embed the plugin
> > UIs, which is something we even manage to do with Ardour on OSX, where
> > we're using GTK and the plugins are using Cocoa or Carbon. this seems
> > like a bit of a backwards step - here we are on a platform where we
> > control *all* the technology and we can't even get the plugin GUIs to
> > embed? shurely shome mishtake ...
> 
> put it another way:
> 
> is there any lv2 plugin which is not using the lv2_external_ui extension
> but is xembed-dable and please, do not force the host to link to libgtk
> et al. and even show its gui?? i'd like to know :)

The UI simply provides a widget of some type (e.g. GtkWidget). Whatever
the host can/does with this is not a feature of the UI. Your question is
a bit misleading (it is obviously impossible to use a GtkWidget without
linking to Gtk). Technically the answer to your question is yes, since
it is possible to XEmbed a GtkWidget. If you mean to point out that the
current situation is inadequate, there's no disagreement there - there
is currently no good solution to that problem (i.e. hosts /can/ do it,
with a lot of work and code duplication, but this is not a good
solution). There is indeed a problem here, but it is a host-side one.

The question is /what/ should link to Gtk. You say not the host, and I
agree. We therefore need something in-between then host and the e.g. Gtk
UI implementation. There are two options:

 * Throw out embedding and various other desirable features, and
re-implement this bridging in every single UI (the external UI
extension's strategy).  Not everyone is happy: nice features become
impossible, and copy/paste code duplication is rampant.

 * Keep all the desirable features when possible, gracefully degrade
when not, and implement this bridging once in a library.  Everyone is
happy: anything possible is, uh, possible, proper code reuse means all
hosts work correctly for free, bugs/features need implementing once,
implementing a UI or UI support becomes much simpler (increasing
adoption), neither host nor UI authors need to care about cross-toolkit
compatibility, etc.

The latter is What Needs Doing. There is IMO no question about that,
it's all win. There are a few details to sort out, though:

The proposed library would inherently need to link to Gtk. This means
the host doesn't directly link to / depend on Gtk, but the library ends
up depending on all toolkits, so from a package perspective every host
ends up depending on every toolkit, which is no good. So, the library
will need to be implemented in several dynamically loaded modules
(ideally packaged separately). I think this is probably the way to go.

If even an indirect dynamic linkage like this is a problem (why?), then
a process based solution is also possible. This will probably be needed
for new stuff like UIs in other languages (e.g. python), remote/web UIs,
etc. I don't think doing it this way is wise/necessary for the current
crop of hosts/UIS, though (all C/C++), i.e. this is non-pressing future
work that shouldn't affect the library API.

> oh, and did i say that the gtkmm based ones are even crappier in that
> regard? because it also forces you (host) to link to libgtkmm, which is
> outrageously and utterly plain nuisance?

The Gtkmm initialisation problem does suck(*), but linking to gtkmm is
no more outrageous than any other toolkit.  Again, just another example
of why this all needs to be wrapped up in a library where we can solve
it once, correctly.

-dr

(* There is, however a simple solution I won't go into now that is also
useful for a few other similar situations)