Re: [LAD] State of Plugin API's

On Sat, 2009-10-31 at 15:32 -0400, Paul Davis wrote:
> On Sat, Oct 31, 2009 at 3:12 PM, David Robillard <dave@email-addr-hidden> wrote:
>
> > They are both literally just mechanisms to get a pointer to some
> > code/data by name. It's really quite simple... I'm not sure where this
> > conception that there's some kind of hard to understand complex
> > mechanism involved here comes from, but there really isn't at all.
> > "Mechanism" isn't even an appropriate word, really, it's just a
> > function. It's as straightforward as straightforward can be. Look at
> > the header:
>
> Nobody has suggested that this is hard to understand.
>
> if i am writing a plugin, using LADSPA or VST or AU etc, and the API
> does not provide some functionality that I would like to use, i am
> stuck. i have to use what is there. end of story.
>
> if i am writing a host that supports those same plugin APIs, and it
> doesn't provide some functionality that i would like to use, i am
> stuck. i have to use what is there. end of story.
>
> If i am wrting a plugin, and the current LV2 spec + existing
> extensions do not provide some functionality that I would like to use,
> then i can create a new extension. excellent.

Fine and good. Except that's not what's usually said, and that's not
what was initially said here. LV2 is, apparently, a "catastrophic
failure". When it's not that, it's usually FUD or misinformation about
the extension idea itself. Excuses and whining, not arguments and
solutions. I agree there is a difference, and more of the latter would
be nice.

> oh, but now i have to get the host(s) to support it. not quite so excellent.

This is true, but inherent. You get one, and only one of the following:

- LV2 as it is currently, and the ability to solve this problem (and the
eventual outcome that they all get solved) and increase the power of the
whole thing

- Nothing at all

You are free to use GMPI if the latter option sounds appealing :)

There is nothing magical about API defined in an extension as opposed to
"LV2". If LV2 was a monolithic specification - well, it wouldn't
actually exist in any finished or usable state at all, but let's make
that huge leap and pretend it is - then this same situation would exist.
Feature foo needs to be implemented by a host regardless. The
difference is, with a monolithic specification feature foo not being
implemented by the host means that host doesn't support anything LV2, at
all, whatsoever, end of story. This is clearly inferior.

> but the extension *concept* requires a level of co-evolution between
> hosts & plugins that is new and unfamiliar to those who have
> previously been involved in both. people who have issues with static
> plugin APIs work to find workarounds for limitations for the APIs.
> that's arguably stupid and the extension mechanism is a much better
> way of tackling the problem.
>
> BUT ... actually using requires interactions betweens host & plugin
> authors in new ways, and *that* is what is hard about this, not the
> design or how to use it.

It requires interactions, but I don't really agree it requires anything
new at all, certainly not in this community. Libraries or plugins,
their interfaces, and the programs that implement/use them always
co-evolve. Of course they do, they either co-evolve or do not evolve
whatsoever and die. It's no different than if it was all crammed into
one kitchen sink specification, then everything still needs to co-evolve
in the same way except the barriers to doing so are MUCH greater, to the
point of basically preventing any evolution whatsoever (a textbook
outcome of bad, non-modular design).

Some people get this, but others just point at the whole thing and
whine, and do nothing. The reasons are purely psychological, not
technical - they don't want to help, and blaming others and the
technology is easier. It is a childish attitude bred by people being
accustomed to gigantic soulless corporations telling them what to do, in
my opinion. It has no place here.

> the new ways have implications for users too,
> because every new extension used by a plugin effectively bumps (or
> branches) the "version" of LV2 that a plugin is using. its no longer
> possible to ask "does a host support LV2?" - a user has to know the
> answer to a much more specific question ("LV2 + extA + extB + ... ?").
> its easy for software to discover the answer to this, but not so easy
> for a user (or even a plugin developer).

In the vast majority of cases, an extension not being supported means
the plugin will work fine but that functionality isn't present in the
host. For example, a command line host may not support GUIs, so the GUI
doesn't work. I don't think this is really all that complicated for a
user to understand, or a problem: a program simply doesn't support GUIs.
It's not like a user has to sit down and enumerate and cross reference
these things or something. It has been designed to gracefully degrade
for exactly this reason.

> this is what i believe jorn meant about "social engineering". you've
> designed a new and better way to evolve a plugin API, but for it be
> successful requires quite different things from the ecosystem than a
> static (and likely inadequate) API. those are things are not easy to
> come by.

Maybe. If he didn't get all trolley and call the whole thing a
catastrophic failure then maybe I would have focused on that part ;)

Arguments about this at a high level are almost entirely pointless
anyway: developers who are actually going to solve the problems will
show up and do so. The kind of people who whine on mailing lists about
it or make up sociological arguments for the lack of this and that
aren't the sort of people who are actually about do it anyway, so who
cares what they think? What could actually be done to magically make
people show up who will do this work? Nothing. A developer who is
interested in making e.g. ramped control ports will show up, or they
won't. The whole thing simply has to grow, which is the only realistic
way to solve a problem like this anyway.

How about this: just pretend LV2 IS a monolithic specification!
Therefore, it does not exist in a finished state yet (just as it
wouldn't), and there is no such thing as LV2. There is no technological
difference between this and reality. If you want to define "the LV2
specification" in your mind as some bloated and completely arbitrary
kitchen sink of features, feel free to do so and consider the entire
thing unfinished and not worthy of implementation at all. Call
extensions "working groups" or whatever to satisfy your bureaucratic
leanings. Is this stupid? Sure it is. But that's basically my
point :)

Obviously I agree things need to be done, but whining about the entire
thing at the meta level is not what needs to be done. Extensions are
(well, should be) tidy little bits of well-defined functionality. When
there is a hole, as you said, you make one, you implement it, and the
problem is solved. As people scratch those itches, all the problems
will be solved.

Itch scratching solves problems, FUD and whining doesn't. Itch
scratching is pretty much the ONLY thing that solves problems around
here anyway. LV2 is simply optimized to exploit this fact of reality as
efficiently as possible, and it's worked pretty well so far. There is
no committee to point fingers at, because you can implement whatever you
like. The only place to point that finger is at yourself.

This way, things get designed and implemented by people who actually
give a damn about those things. The end result is quality software.
Calling the whole thing a catastrophic failure is, frankly, complete and
utter bullshit, and spreading that kind of opinion only HURTS progress.
Someone may skim through the list, see that, and decide that LV2 is a
failure and thus not worth investing in or implementing, which is
completely untrue (and happens). I call it FUD for a reason, it damages
LV2 in exactly the same way a certain notorious company damages others
with FUD. People not actively helping doesn't really irk me so much -
but people doing this certainly does. LV2 is no failure, but keep
sabotaging it in that way and maybe it will be. Pointing out that the
community engineering aspect is a failure and then doing precisely the
thing that damages it the most is a teeny bit hypocritical, isn't it?

There is no inherent problem with LV2, there are only jobs to do - and
they will get done, eventually. Most likely by people who spend more
time typing into their text editors than their email clients. End of
story.

-dr

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sun Nov 1 00:15:02 2009