[LAD] State of Plugin API's

Paul Davis paul at linuxaudiosystems.com
Sun Nov 1 16:24:58 UTC 2009

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

with LADSPA, it was very easy to motivate discussions about design
changes - there was one header, and it got into the header, or it
didn't. 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. people can do
whatever the hell they want (good!) and nobody else need care (bad!).
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. 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.

More information about the Linux-audio-dev mailing list