On Fri, Nov 6, 2009 at 6:08 AM, wrote:
fons, although i share some of your concerns about LV2's design
philosophy, I don't think its fair to conflate this particular issue
with extensions at all. there's no evidence here of any "conflict"
between extensions. there was a revision to the core specification,
and it was a fairly deep revision at that, albeit a small one. this
made one (and at this point, it really does look like one) extension
that was written using an older version of the spec now technically
invalid (even though in practice it still works). this could
theoretically happen any time that the core spec is modified, and it
underlines how much more important it is for that to remain stable if
useful functionality is developed in the more "ad hoc distributed" way
that the extension mechanism provides for. but i really don't think it
says *anything* about the extension mechanism at all.
> I'm not going to spend even a minute writing a plugin or
having seen the breadth of functionality offered by both VST and AU
plugins, using APIs that in almost all respects provides no more
functionality than LV2 core + some GUI extension, its hard for me to
imagine what extensions you might want to be using in the context of a
general purpose host like ardour. this is a clue:
>All of them
Harrison faced precisely this problem with mixbus (if you haven't
noticed this yet, http://mixbus.harrisonconsoles.com/). They decided
to take advantage of the fact that the host is open source and that it
was less productive to try to define a *plugin* API that provided the
required level of interaction with the core of the app. So they just
hacked Ardour's code itself (even though the actual DSP involved is
still in a LADSPA plugin).
> There are much simpler solutions available. If I define each
your preferred solution depends, fundamentally, on how much you
*really* want some/all of those plugins to be re-usable. To take the
Harrison case as an example, again: the plugin in that case is
fundamentally *not* reusable outside of mixbus, even though its using
an API that isn't ardour specific. if you *really* want your "type A"
plugins to be reusable in other contexts, then *of course* you would
develop them using a non-host specific API. LV2 might be highly
appropriate for that, or not. But if you don't really care about that
reuse, then of course your common, host specific API makes more sense
and is less work.
so, i don't really see this as having much to do with LV2, its current
state or its design philosophy. i'd also note that while i too have
been critical of LV2's design, i don't see anything else that can move
us past the state of affairs that LADSPA represents. to the extent
that the future of open source cross-host audio plugins, at least for
linux, requires such an API, i think that LV2 is it. it does need some
"social engineering" (i think that this is what jorn called it), but
thats entirely different from postulating that the extension-based
design is fundamentally flawed.
Linux-audio-dev mailing list