10 Aug
2009
10 Aug
'09
6:26 a.m.
David Robillard 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).
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
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.