10 Aug
2009
10 Aug
'09
1:52 p.m.
On Mon, 2009-08-10 at 11:41 +0200, Fons Adriaensen wrote:
On Mon, Aug 10, 2009 at 10:26:34AM +0200, Jörn
Nettingsmeier wrote:
In this domain, it seems pretty clear it's the only one that works...
Consistency problems are simple to deal with, e.g. lv2plug.in can
provide a nice centralized list of extensions and documentation if they
fit certain guidelines. There is a page working towards these here:
http://lv2plug.in/docs/index.php?title=Extension_Conventions
As with everything else, it's not a problem with the tech, it's just
work that somebody needs to do. Welcome to free software. People
whining about the decentralized nature are really just whining that
someone else hasn't done it for them ;)
If you want to be able to point a finger and blame a dictator for
something being crap, use VST.
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.
And the primary design goal of virtually all languages is to allow
modular decomposition of functionality. Hmmm...
Would a language with no encapsulation (including user defined
functions) and only keywords be a good language? You can't define
everything that you do with a language in the language itself (for a
sufficiently powerful language). Similarly, you can't define everything
that you do with a plugin in the plugin spec itself (for a sufficiently
powerful plugin spec).
A good language defines a simple and consistent framework on which
you /can/ build whatever you want. This is precisely what LV2 does.
Extensions are analogous to modules/objects/abstract interfaces
(depending on language).
Any language worth using has a comparable mechanism. LADSPA, for
example, doesn't, which is exactly why LADSPA is as weak as it was
nearly 10 years ago when it was designed. LV2 currently is a heck of a
lot more powerful than it was when it was designed, and gets better all
the time. The reason for this is precisely that it was designed to
provide a basic framework that can be extended, and not defining
absolutely everything up front (which would have failed outright).
There's not much sense in arguing about the merits of it at this point,
look at reality.
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 suits you more :)
Of course it should be analysed in a systematic way. If you think this
is in conflict with extensions, you are very mistaken. Being able to
sit down and tackle this problem on its own is the whole point!
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.
Mathematician's don't usually wave their hands quite this much ;)
The plugin obviously does know about all its inputs (or is free to
ignore some). LV2 does reflect this systematic nature, because all I/O
is still based on ports. This is the reason mentioned earlier why using
multiple instances for this is wrong.
Re: the hand-wavey FUD bit: they are not partial problems or special
cases, they are complete, independent problems. Again, this is straight
out of good design 101. SOMETIMES functionality is relatively large and
intertwined, in which case the extension for it would also be large and
encompass a lot (in the other direction, yes, an extension that solves a
partial problem or a bunch of special cases is also crap). In these
cases, there will be a sound logical argument why things need to be
combined in the same extension. Doing things this way without that
sound logical argument is simply textbook crap design.
There may even be an argument for something going in the "core" spec.
This is extremely, extremely unlikely, but it's possible. Big deal, we
release another revision. It's happened before (minor stuff), it will
happen again, nothing breaks. Again, without the logical argument for
doing so, it's just swingin' hands. The sky is not falling.
Coming up with those arguments = productive discussion, gets things done
Flinging FUD about extensions = worthless noise
You can consider LV2 itself a "work in progress" and all work on
extensions "part of the LV2 committee" or whatever if you like. There
is no difference. The work in progress just happens to be useful and
working right now.
I don't think anyone can claim with a straight face the fact that we
have working plugins with MIDI, and GUIs (both embedded and separate
process), and presets, and dynamic plugin wrapping, and (etc etc etc) is
a bad thing. Pudding.
Anyway, to bring this silliness back into the realm of concrete useful
things, replication in basic form is pretty straightforward: the host
needs a way to pass a 'replication factor' to the plugin. This raises a
few obvious questions:
- Should changing this at run-time be possible? This is more useful
with polyphony than with replication for multi-channel purposes. This
raises nasty realtime issues, but since buffer allocation is the host's
problem and a clever host could possibly do it, I think the spec should
make this possible. Maybe there are problems with internal plugin data
that needs to replicate as well but in a non-realtime way though?
- Do different ports/groups need different replication factors?
- Does the plugin need to be able to refuse a factor dynamically, or can
acceptable ranges just be defined in the data? (latter is better unless
there's a compelling reason for the former)
Cheers,
-dr