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 _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
