[LAD] the role of lv2 extensions

Jörn Nettingsmeier nettings at folkwang-hochschule.de
Mon Aug 10 08:26:34 UTC 2009


David Robillard wrote:
>> Building this logic on top of a set of optional
>> extensions would seem to be a nightmare, and that is and always
>> has been my main objection to this approach.
> 
> FUD, nothing more.  It would be no more of a nightmare than implementing
> it on top of... well, anything else; presumably you mean something
> defined in "The LV2 Specification"(TM).  No offense but I doubt you
> really understand the mechanism judging by this comment.  That
> "nightmare" (a.k.a. "good design") is exactly what will allow all of the
> above to be solved.  Proof is in the pudding, as they say.
> 
> -----
> 
> Aside: Since this seems to be misunderstood frequently, I'll harp on the
> point a bit for the list in general (this is an explanation, not an
> invitation to argument):
> 
> There is absolutely nothing second class, or (necessarily) optional,
> about LV2 extensions.  A lot of thought has been put in to the
> extension/feature concept/mechanism, and it has been carefully designed
> specifically so that it is not a "nightmare".  Solving the above
> problems in "extensions" is not worse than if we were to ram it into the
> "core" spec itself.  There is nothing inferior about it (wannabe
> dictator arguments aside, anyway).  There are many things superior about
> it, however.  The most important is social: nobody on this list needs to
> be convinced that having one specification define absolutely everything
> is a sure-fire way to have any potentially productive discussion devolve
> into endlessly long threads that end up nowhere because nobody can agree
> on what's "needed" and what isn't.  Extensions are simply a
> modularisation of this process: problems can be solved independently by
> people who care about those particular problems.  You can even work on
> actual implementations of things to test them out without any
> compatibility problems whatsoever.  So, we have nice tidy little
> tractable problems, that can feasibly be solved well (see: UNIX).  The
> end result is: the problems actually, really, can get solved.

i guess part of the irritation around (and possibly delayed endorsement
as compared to LADSPA) of lv2 stems from those "extensions".

from a design standpoint, i totally agree with all your points, and what
little i've so far grokked of lv2 looks very nice indeed. *but*: it's a
moving target, and few host authors have committed themselves to
implement those extensions.

the problem i see: the extensions mentioned on the lv2 website are of
very different maturity, it's absolutely not clear which of those should
be considered "canonical" and hence a *must-implement* feature, nor has
there been any public discussion about any canonical set of core
extensions (excuse that weird expression, but i can't think of anything
better).

crooked analogy alert... as it is now, lv2 resembles XML: you can do
anything in principle, but there is almost no common semantics. we
should move it to XHTML: define a set of mandatory extensions that
everybody can expect to work pretty much everywhere (to the extent that
it makes sense - i understand a synth host might have different
priorities than, say, ardour).


best,

jörn




More information about the Linux-audio-dev mailing list