On Sun, 2009-11-01 at 09:44 +1100, Patrick Shirkey wrote: > On 11/01/2009 08:11 AM, David Robillard wrote: > > On Sat, 2009-10-31 at 15:32 -0400, Paul Davis wrote: > > > >> On Sat, Oct 31, 2009 at 3:12 PM, David Robillard<[email protected]> wrote: [...] > >> 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. > >> > > Fine and good. Except that's not what's usually said, and that's not > > what was initially said here. LV2 is, apparently, a "catastrophic > > failure". When it's not that, it's usually FUD or misinformation about > > the extension idea itself. Excuses and whining, not arguments and > > solutions. I agree there is a difference, and more of the latter would > > be nice. > > > > > > To be fair it was in the context of adoption not as an overall sweeping > statement about the entire LV2 system which everyone agrees is a very > powerful and flexible model for plugin development and IMO deserves > greater recognition as best of breed in open source thinking and wider > adoption from the worldwide community of plugin developers.
Fair enough :) > > There is nothing magical about API defined in an extension as opposed to > > "LV2". If LV2 was a monolithic specification - well, it wouldn't > > actually exist in any finished or usable state at all, but let's make > > that huge leap and pretend it is - then this same situation would exist. > > Feature foo needs to be implemented by a host regardless. The > > difference is, with a monolithic specification feature foo not being > > implemented by the host means that host doesn't support anything LV2, at > > all, whatsoever, end of story. This is clearly inferior. > So, maybe it would be a good use of time to resolve this inadequacy as a > priority before moving onto other items? ? The inadequacy is with a hypothetical monolithic alternative to LV2, not with LV2. If LV2 attempted to go this way, there would be /zero/ adoption... -dr _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
