10 Aug
2009
10 Aug
'09
7:41 a.m.
On Mon, Aug 10, 2009 at 10:26:34AM +0200, Jörn Nettingsmeier wrote:
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).
The evolutive process described and advocated by Dave is
certainly one that can work - it is the way e.g. natural
languages get defined and change over time. It's also why
they tend to be inconsistent and why you need to study a
lot more grammar than would be required otherwise.
This should be compared to the (in most cases) quite
consistent syntax of computer programming languages.
And in the end, a plugin interface is a language that
has to be understood by both the host and the plugin.
Regarding the replication problem ("How to structure
a basic mono plugin, its host and their interaction so
the plugin can be used in a variety of multichannel
contexts having different requirements"), this is
something that can be and IMHO should be analysed
in a systematic way.
I'm just wearing my mathematician's hat of course.
It boils down to graph theory, the way an algorithm
can be split up and the order in which some steps must
be performed. As as simple example the multichannel
limiter must see all inputs before it can produce the
first output, while an EQ would not require this.
Things get mildly more complex if you also consider
parallel execution, but this still can be analysed.
Given a number of reasonable constraints this leads
to a finite number of possible processing graphs,
and these can be decribed in a systematic way. Any
plugin interface should IMHO reflect this systematic
nature, and not be a collection of ad-hoc solutions
to partial problems and special cases.
Ciao,
--
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.