[LAD] the role of lv2 extensions

David Robillard dave at drobilla.net
Mon Aug 10 15:02:53 UTC 2009


On Mon, 2009-08-10 at 10:26 +0200, Jörn Nettingsmeier wrote:
> 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).

This is a problem with the site, not the tech/spec.  I very much agree
the site needs work.  We need to install a CMS and have a more community
driven site etc.  Anyone who wants to help out with this, please do...

I have been working on automatic documentation generation for
specifications to address part of this problem.  This page is generated
automatically from the port groups schema, for example:

http://lv2plug.in/ns/dev/port-groups.lv2/port-groups.html
  
> 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

"mandatory" in this top-down dictatorial sense is not useful.  Plugins
or hosts can make things mandatory if they want.

>  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)

Exactly.  If some things don't work, then they inherently don't work.
It would be no different if the various features were all defined in a
single spec.

There is no problem with things not working.  Hosts that don't support
e.g. dynamic polyphony .... well, don't support dynamic polyphony.  A
well-written plugin gracefully degrades anyway, most extensions make
this possible.

Cheers,

-dr





More information about the Linux-audio-dev mailing list