Re: [LAD] [ANN] IR: LV2 Convolution Reverb

On Mon, Feb 21, 2011 at 7:20 PM, David Robillard <d@email-addr-hidden> wrote:

> 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
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-dev
>

Hi David,

As a plugin developer, I'm very much looking forward to this, especially
since I proposed something similar to this a bit ago (
http://www.opensubscriber.com/message/linux-audio-dev@email-addr-hidden/14098999.html
:)
  But the fact that you're capable and willing to implement this solution
means a lot more than my confused half-baked ideas. I look forward to the
day when embedding and cross-toolkitedness walk hand in hand.

Jeremy

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Tue Feb 22 08:15:03 2011