6 Nov
2009
6 Nov
'09
8:17 a.m.
On Fri, Nov 6, 2009 at 6:08 AM, <fons(a)kokkinizita.net> wrote:
This could have been done as an extension. I agree
that would
have created some chaos, so changing the core spec was probably
a wise choice. But that's the point: this can happen at any time
with extensions. If you have N extensions, how big is the chance
that not any subset of S <= N of them will not be in conflict
somehow ?
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
a set of them, requiring maybe five new extensions, if I'm
not absolutely sure that these extensions will be accepted
(that is: implemented) by the authors of the major host
programs, e.g. Ardour.
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
require _embedded_ GUIs, to the point that a user will
not even be aware that some parts of the app are plugins.
Some of them require quite complex interaction with the
core of the app, not just a set of audio and traditional
control values.
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
of A,B,C as a C++ base class then any .so that provides a
factory for a derived class of any of them is a plugin. And
that's it. Of course this could mean issues with C++ binary
compatibility, but in this case, given that most of this
will never be used elsewhere anyway and distributed as a
single package, I accept those.
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.
--p