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

On Mon, 2011-02-21 at 20:27 +0000, Rui Nuno Capela wrote:
> On 02/21/2011 07:20 PM, David Robillard wrote:
> > On Wed, 2011-02-09 at 20:05 +0000, Rui Nuno Capela wrote:
[...]
> >> 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.

I said the LV2 UI extension is toolkit agnostic. It is - i.e. it
supports any toolkit.

I did not say all particular LV2 UIs are toolkit agnostic. They are
not. Many are implemented in Gtk, for example. This, however, is not
the problem (as we both agree, i.e. UI authors should be free to do so).

> 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:)

Well, sure, but you can't say that not having LV2 UIs whatsoever would
be a good thing with a straight face. Nobody's claiming everything has
been done perfectly. I will, however, claim that the freedom for
developers to do their thing does result in real, actual, innovation,
and improvements in the 'LAD platform' that would not occur otherwise,
and history backs me up. That developers can do their proof of concept
implementations is certainly not a bad thing! It's a very, very good
thing, that has been shown to work.

Of course, this freedom comes at a cost, no argument there. We do
indeed need to revise how those proof of concepts were done (with the
benefit of the experience gained) from time to time. Sure beats not
being able to...

That's the cost - the reward is higher quality software (eventually),
more features, and all the well-known wins that come with
distributed/agile software development. Particularly in an open source
world, it's IMO a very wise trade-off.

Anyway, back to practical matters:

> 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

I fully agree, which is why I just described my proposed solution to the
problem. Again, I don't tend to discuss such things on-list much (the
pointless direction of this discussion being evidence as to why), but
developers need to know a particular technology is not a
wise /long-term/ investment to make the best decisions, and the issue
came up, so...

> , is a
> lot more wrong than using Nedko's lv2_external_ui extension.

Well, no, because that extension threw out the baby with the bathwater,
and while it solved a pragmatic part of the problem in the short-term,
it made the serious long-term problem here (API) even worse in some
sense.

The problem is not how plugin authors have been doing their GUIs at all.
They have been, can, and still should, be implementing them in their
toolkit of choice, such as Gtk. The problem is that it was not
implemented correctly on the host side of things, and instead of solving
this problem once correctly and collectively (library), the external UI
extension kludge screwed up the UI API instead, put the solution in the
wrong place, forced that solution to be constantly re-implemented, and
further fragmented the community. Long term problem => alarm bells =>
fix needed.

Note that the problem here is not the LV2 UI extension, which will not
have to change(*). That it may be the pragmatic choice for plugin UI
authors right now does not change the fact that the external UI
extension was (objectively and without malice) the design screw-up here.
Fair enough, the ability to try and screw it up is a part of that
freedom. I've certainly screwed up my fair share as well. Live and
learn... and revise :)

-dr

(* Which, by the way, is a real-life example of the LV2 extension way of
things working)

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