31 Oct
2009
31 Oct
'09
4:32 p.m.
On Sat, Oct 31, 2009 at 3:12 PM, David Robillard <dave(a)drobilla.net> 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.
oh, but now i have to get the host(s) to support it. not quite so excellent.
if i am writing a host then .... ditto ...
nobody (certainly not me) is suggesting that there is anything *hard
to understand* about this. the extension mechanism is well designed,
easy to use and supremely flexible.
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. 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).
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.