On Wed, 2009-10-28 at 16:59 +0100, Jörn Nettingsmeier wrote:
> to be very frank, i think the lv2 process showed that no matter how
> brilliant your design, if you fuck up the community engineering aspect,
> you're doomed. LADSPA could be implemented in minutes by a braindead
> zombie (hell, even yours truly managed to write a plugin or two), and
> see how people jumped at it - adoption rates were spectacular.
> compared to that, lv2 was a spectacular failure.
Implementing an LV2 with the same capability is every bit as easy.
Like many complaints about LV2, this really just amounts to whining that
someone else hasn't done everything for you already. That's not a
failure of community engineering, that's a shortage of time and people
to actually do the work. This is hardly a new thing in LAD. There are
simply not that many developers around, and things take time. LV2 now
is a lot more powerful than LV2 when the spec first came out, and LV2 a
year from now will be a lot more powerful than it is now. If you think
LV2 "was" (?) a spectacular failure, you clearly aren't really paying
attention. "Failure"? Why, exactly?
The extension approach IS community engineering. It allows YOU, or
anyone else, to actually do the work. A monolithic specification just
results in an endless war on mailing lists, and allows NOBODY to
actually do the work.
(*** If you read nothing else in this email, read this ***)
Blaming the mechanism for this is complete nonsense (and people trolling
and spreading FUD by doing so has gotten /really/ old). This is exactly
like blaming the shared library mechanism for the fact that there's no
open source shared library to do realtime granular resynthesis, or
whatever. Think about how absurd this is! Would you start sending
emails to your OS distributor because there are no shared libraries for
realtime granular resynthesis, because their "shared library" pie in the
sky technology somehow prevented it from being done? Of course not,
that's completely ridiculous! The mechanism is what makes it possible
to implement such a thing. Does complaining about the shared library
mechanism in this way sound really stupid? It should. Complaining
about the LV2 extension mechanism for a lack of implemented extensions
is exactly the same thing.
The problem is simply that NOBODY HAS WRITTEN IT YET. Enough with the
FUD, please.
The only thing really lacking in terms of community/PR IMO is the
website, which is static, stagnant, and not particularly good anyway.
It should probably be nuked and either everything moved to the wiki, or
replaced with a CMS. The former is easier since there's already a wiki,
the latter is fancier and more professional looking.
> let's take the lv2 technology, get a set of canonical extensions that
> every plugin author can expect to be present on every host worth its
> salt, and drag it to "critical mass" :)
Let's indeed. Feel free to get started any time now ;)
Though there's not really a need to try and do this "canonically".
What's 'clearly necessary' for one plugin is completely useless for
another. An extension is supported or it isn't, in the vast majority of
cases the plugin/host can easily just not use if it isn't there. The
only real potential problem is when multiple extensions get created for
the same thing. As long as people cooperate (via the mailing list
and/or wiki) and create high quality extensions this should not be a
problem.
-dr
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Sat Oct 31 20:15:02 2009
This archive was generated by hypermail 2.1.8 : Sat Oct 31 2009 - 20:15:02 EET