[LAD] [ANN] IR: LV2 Convolution Reverb

[David Robillard]

On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela wrote:
> On 02/09/2011 04:49 PM, David Robillard wrote:
> > On Fri, 2011-01-14 at 21:29 +0100, Tom Szilagyi wrote:
> >>
> >> Regarding LV2 hosts other than Ardour: the second in the above list of
> >> fixes should help, however please be aware that IR is at the moment
> >> really not usable without its own GTK UI. In future versions I may
> >> manage to switch to using an external-process LV2 UI which would
> >> result in the plugin UI being completely host toolkit agnostic.
> > 
> > FWIW, I would not do this.  The external UI extension is the wrong way
> > of going about this, and momentum towards it is very worrysome...  We
> > need an abstraction layer (i.e. a library) to provide the ability for
> > any UI to be external.  It shouldn't be the host's - and very definitely
> > not the plugin's - problem to do this.  It's a difficult problem to get
> > just right(*).  Even if it wasn't, we'd end up with the same code
> > implemented all over the place, which is an obvious sign something is
> > not right...
> > 
> > The right way is for the plugin UI to provide whatever native UI (e.g.
> > gtk) it pleases, and a library provides the means to launch it
> > externally if the host toolkit does not match.  This way, the host can
> > embed the UI if possible (a feature which really is a shame to throw
> > away), but anyone can use it externally if this is not possible.  It is
> > also possible these days for Gtk to embed Qt, and vice versa, which the
> > lib could also do... in short, all the tricky business of using an X UI
> > in a Y host, either embedded or externally, needs to be done in one
> > place, and done in that one place correctly, so every host/plugin author
> > doesn't have to repeatedly deal with the same problems.
> > 
> > After the upcoming LV2r4 (and new librdf-free slv2) is released (soon),
> > I will take a stab at making this library.  All the nitty gritty has
> > been done by other people already, it just needs to be sanely
> > amalgamated.
> > 
> 
> your words, Dave, are wise, but... until that (yours?) lib gets ever
> real, the lv2-external-ui extension won't ever be wrong. sorry to tell

Just because something right has not been implemented does not mean the
existing thing is right... (as your Gtk gripes illustrate)

Yes, clearly right now (excluding actually implementing the library),
using it is the pragmatic decision if you want a UI that works in a host
of any toolkit (and you don't need to embed UIs).  This situation,
however, is crap, and needs fixing.

> what has, and still is, outrageously wrong is that utter cannot-say-what
> stickiness to gtk gore over the lv2-ui interface--it's real pain (gasp)
> lock-in disease--mostly due on ardour being a top reference as a plugin
> host, nevermind being a gtk based one (and damn good at several other
> things too;)

What?  The LV2 UI extension is toolkit agnotic.  It is not gtk based
whatsoever.  Permit me a bit of yelling for emphasis:

PLEASE DO NOT SPREAD THE MISINFORMATION THAT THE LV2 UI EXTENSION IS GTK
BASED, OR BASED ON ANY OTHER TOOLKIT.  IT IS NOT, HAS NEVER BEEN, AND
NEVER WILL BE.

Sure, you (as a Qt person) don't like that most existing UIs happen to
have been implemented in Gtk.  This is a problem with how we have
implemented UIs though, and not a problem with the UI extension itself.
That is, this is precisely the sort of problem that shows we need a
library to abstract this stuff (i.e. you are perfectly free to implement
Qt UIs, but then Gtk host authors have the same gripes).

I fully agree host authors should not have to deal with this (I
certainly don't want a bunch of Qt crap in my Gtk hosts either), that's
the entire point.  I take it further and don't believe plugin UI authors
should have to deal with it either.

We can get all the wins without:

 * Throwing out UI embedding, which really sucks for a lot of potential
UI designs (window hell sucks).

 * Forcing a particular toolkit, which will inevitably piss off everyone
who doesn't like that particular toolkit, again really suck for a lot of
potentially neat UI designs, and thus severely hurt adoption

 * Making plugin or host authors 

Why throw out nice things if we don't have to?  Kludges in
implementations are fine, but kludges that affect what interfaces we
cooperate using are dangerous, particularly in the long term...

> please, don't give me nice talks about xembed and that stuff about gtk
> and qt widgets being reciprocally embeddable. it just doesn't work for
> the masses. well, in practice, unless you're in some kind ivory tower
> and aim for a very special case or tight coupled application, that is...

I am told it can work these days, unlike in the past.  Torben has some
experiments along those lines that work for him and at least some
others, but one direction (I can't remember which) didn't work for me.
Maybe it is indeed unrealistic, at least in some situations.  It doesn't
really matter regardless, the design decision of where the
embed/external/whatever stuff belongs is orthogonal.

In other words, maybe embedding toolkit X in toolkit Y can work, maybe
it can not.  I am not sure, nor do I really care so much.  My point is
definitely not that we should all depend on cross-toolkit embedding
working; the important point is that this problem (e.g. using a Gtk UI
in a Qt host) needs solving once, not a million kludgey times in every
host and UI implementation.

I do intend to write said library myself soon (I don't often talk about
what I/we "will" do, but this is something of an LV2 UI state of the
union).  It is a high, but not top, priority for me right now (somewhere
after releasing LV2r4, the new librdf-free slv2, and the LV2 persist
extension).

The important part, that I am suggesting very much needs doing ASAP, is
that getting a library interface implemented, so people can start using
it.  This does not depend on making embedding working, since the
fallback will be making an external windows.  We simply need something
like (obviously a simplification):

OpaqueWidget
lv2_ui_lib_load(ToolkitType requested_toolkit,
                UI          plugin_ui)
 
Which will return a widget of the requested toolkit type, regardless of
the toolkit the UI is implemented.  There's a few possibilities:

 1) Hooray, the toolkits match, and this will directly return the UI
widget, which you can embed or do whatever else you want with.

 2) The toolkits do not match, and the library can implement
cross-toolkit embedding.  This will return a widget in the requested
toolkit that from the caller's perspective is the same as case 1.

 3) The toolkits do not match, and cross-toolkit embedding is not
possible.  This will do the external UI thing (i.e. make a window, and
return a corresponding widget).

There are, in general, the 3 cases.  The jist of the current problem is
that implementers must make a decision that mandates an interface on
other implementers.  The library will make this problem go away, and
make these cases implementation details as they should be.

This is very much a pragmatic path, and not at all an ivory tower / pie
in the sky situation: whether or not a case (particularly 2) can work in
a given situation doesn't really matter - we have gained graceful
degradation and interface stability.  The first version will simply
implement cases 1 and 3 - providing the interface is the important part
that will solve the pressing problems with this situation.

Hopefully someone will figure out and contribute case 2, but this is not
a pressing (i.e. API related / community fragmenting) problem - just a
nicety.

Peace,

-dr