Re: [LAD] the role of lv2 extensions

From: Fons Adriaensen <fons@email-addr-hidden>
Date: Mon Aug 10 2009 - 12:41:11 EEST

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.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Aug 10 20:15:06 2009

This archive was generated by hypermail 2.1.8 : Mon Aug 10 2009 - 20:15:06 EEST