[LAD] [ANN] IR: LV2 Convolution Reverb

Rui Nuno Capela rncbc at rncbc.org
Mon Feb 21 20:27:19 UTC 2011


On 02/21/2011 07:20 PM, David Robillard 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).
> 

Dave,

please,

you certainly know that most lv2 gtk plugins out there do break this
whole "agnostic" paradigm--tell me one which doesn't? yep. the ones on
lv2_external_ui. shall i rest my case? no.

if you look closer most of those ill-behaved lv2 gtk plugins, the ones i
brag about, are committing the mortal sin of realizing a gtk(mm) widget,
hardly Xembed-dable. look, it's not even a toplevel window for X sake
(nb. the X is for X, not for Christ)--this seems to be a gross mistake
from all early lv2 ui extension times when most people involved just
wanted to pull up a proof-of-concept gui or something. it turned out the
code base has spread like amoeba (i'm avoiding "viral" intentionally:)

i'm not, and never was, against plugin developers doing their guis with
whatever toolkit they like. it's just that the way they've been doing,
and i suspect spreading like a "copy-paste" anti-pattern somehow, is a
lot more wrong than using Nedko's lv2_external_ui extension.

alas, for some reason, calf and linuxdsp are using it and with great
success. should i say more? maybe not.

anyway, i do acknowledge and really do empower your ideas, which i also
believe will get to a better solution. i just don't take it so lightly,
just like you said, like a "Qt guy" shoudln't -- yes, our notion of
"crap" is reciprocal, trust me ;)

cheers
-- 
rncbc aka Rui Nuno Capela
rncbc at rncbc.org




More information about the Linux-audio-dev mailing list