[LAD] State of Plugin API's

[David Robillard]

On Sun, 2009-11-01 at 12:24 -0400, Paul Davis wrote:
> On Sun, Nov 1, 2009 at 12:14 PM, David Robillard <dave at drobilla.net> wrote:
> > On Sat, 2009-10-31 at 23:38 -0400, Paul Davis wrote:
> >> On Sat, Oct 31, 2009 at 9:09 PM, Patrick Shirkey
> >> <pshirkey at boosthardware.com> wrote:
> >>
> >>    [ ... stuff .... ]
> >>
> >> the idea occured to me sometime today.
> >>
> >> "my host supports LV2-E1"
> >> "my plugin requires LV2-E2"
> >> "this application uses LV2-E<N>"
> >>
> >> EV<N> = LV2 core + { extA, extB, extC .. }
> >
> > Trying to put the entire "extension ecosystem" on a linear scale is
> > definitely completely impossible.
> 
> specifically *not* the entire extension ecosystem.
> 
> subsets of the ecosystem that can be named, referenced, referred to,
> *developed against* by plugin/host authors, with some expectations.
> 
> when you give examples from the web, i think there is an interesting
> lesson there. people with an interest in extending "html" in some way
> (e.g. embedded svg, theora, whatever) know what the path is: develop
> the technology/specs/etc, get some initial implementations, push
> toward w3c ... adoption by w3c (if you're lucky).
> a similar path exists for LV2 except for the last part. you can argue
> that its the cart before the horse - develop the stuff first, then
> lets argue about how its to be part of a named "ensemble" or
> "standard" or whatever. but i would contend that part of the reason
> for a reluctance to develop (which you pointedly referenced) is the
> lack of any clue what happens *after* that. you know, its great that
> LV2 lets anyone and their mom define a cool new way to do ramped
> plugin parameter control. but so what? how is that of any interest to
> someone who wants to figure out, not just a technical solution to the
> issue, but an accepted, in-use engineering solution? if the pathway to
> the second part isn't clear, the first part is less likely to get
> done.

Meh, I don't think that's true at all.  All of this stuff is not a
barrier to anyone actually doing the work at all.  Honestly, be
realistic.  What kind of developer on a mission to get ramped control
ports sits down to solve the problem and goes OH GOD THERE'S NO W3C
STANDARDS BODY TO SUBMIT TO THAT WILL FOLD THIS EXTENSION INTO SOME KIND
OF META STANDARD WITH A FANCY NAME THEREFORE MY EFFORTS ARE WASTED!

Please ;)

These developers DO come along and they DO do things.  Stefano, who is
also participating in this discussion, is a good example.  He showed up
a little while ago on a mission to get dynamic plugin discovery working,
things were discussed on the list as necessary, and things got done.
Reality.  Notice the common theme around here of people who havn't
actually looked into doing anything at all like to scream endlessley
about these supposed problems, but everyone who actually /has/ either
doesn't participate at all, or actively disagrees?  It's not a
coincidence, because these problems are completely fictitious.

> with LADSPA, it was very easy to motivate discussions about design
> changes

And even easier for them to go nowhere at all...

>  - there was one header, and it got into the header, or it
> didn't.

Which in reality, after the initial one is out, means it didn't, ever.

Use LADSPA if you think that plan is so fantastic.  It's no coincidence
that it's a complete and utter joke power-wise compared to all of its
competition.

> its similarly easy, when necessary, to do the same for JACK -
> once again, there is  one header, one API and something is either in
> or out, or modified. LV2's glorious anarchy means that there is no
> social necessity for any convergent effort at all.

Of course there is, multiple extensions for the same thing really sucks
for everybody involved.  That is the social necessity.  If you think
some kind of fascist design dictatorship of LV2 solves this better than
evolution, I direct you to Linus' recently famous comments on lkml about
this one ;)

You say it's easier to modify Jack and LADSPA than LV2.  This is so
wrong it hurts.  How do you add functionality to LADSPA?  You fight
endlessly on this list and nothing gets done.  It's happened countless
times before.  How do you do it for LV2?  YOU JUST DO IT!  It is
provably easier, because the actual task is the same, except there is no
bureaucratic overhead.

If you really wish to argue this point, then I will present a simple
challenge: design and implement ramped control ports for LADSPA, and I
will do so for LV2.  The winner is whoever gets it working and
implemented without breaking any standard - that is, gets it working in
the real world.  You would obviously be insane to accept this challenge,
because actually improving LADSPA is so insanely hard it's basically
impossible, and there is no barrier whatsoever to actually improving
LV2.  I'd be done by the time you even get a reply to your first email
about it in the ensuing never-ending discussion that goes nowhere.  Your
assumption is so false as to be almost completely backwards.  LV2 is,
literally, a LADSPA that has been minimally modified so it can actually
be improved easily.  That's the whole point.
 
>  people can do
> whatever the hell they want (good!) and nobody else need care (bad!).

You can't dictate care.  People care because they need the features.
Duh.

> ok, so people don't agree yet on how to do plugin API feature X ...
> then we need a mechanism that does more to force us to actually come
> up with solutions. LV2 doesn't do anything to force this, possibly by
> design.

How exactly do you propose to force people to solve these problems?
Come over to my house and put a gun to my head?

You can hint that ways of "forcing" everyone to conform to some gigantic
arbitrary specification is needed all you like, but the reality that LV2
actually exists and is useful and gets better all the time proves you to
be wrong.  Bad solutions to imagined problems using common fallacies
(appeal to (non-existent) authority).

>  its no suprise, therefore, that people who might feel a
> pressing need for this or that don't do anything about it, because its
> not actually clear to them that it will be a "solution" at all.

Clearly false.  Why isn't it clear?  There's obvious hooks for you to
implement new functionality, many examples of how to do so, and - hey -
if you do it, you can get the whole thing really actually working,
without having to piss away all your time arguing on mailing lists about
something that doesn't even exist yet.  Again you're painting reality
with a completely inverted brush - it's clear with LV2 that your
solution will be an actual solution, because you can actually get it
working and deploy it in the real world - guaranteed.  Is this clear
with LADSPA?  Hardly.  The situation is pretty much the exact opposite -
it's not really worth it spending the effort to try and extend LADSPA,
because everyone is going to disagree anyway, your efforts will never
hit the real world, and it won't be a solution.  Trying to extend LADSPA
is a complete waste of time in the real world, and trying to extend LV2
is not.  No sense in even bothering to argue otherwise, since the former
does not happen, and the latter does all the time.  Might as well argue
the sky isn't blue.

-dr