On Thu, 2009-11-05 at 22:21 +0100, fons(a)kokkinizita.net wrote:
On Thu, Nov 05, 2009 at 01:18:53PM +1100, Patrick
Shirkey wrote:
On 11/05/2009 08:48 AM, Gordon JC Pearce wrote:
Implement it as a DSSI. It's much easier and
cleaner than LV2, and you
don't need to link to complicated, fragile and bloated RDF libraries.
LV2 is a good intellectual challenge, but not much cop for writing
usable plugins.
Why do you always say such inflamatory remarks like this?
The first part of Gordon's post is based on falsifyable claims,
hence it is legitimate. The second part may be opinion, and no
argumentation is provided, but still I see no reason to ban it.
I have two questions to the LV2 consortium (by which I mean the
group of developers actively advocating LV2).
Q1.
On the LV2 website, Lars Luthman's UI extension is described as:
"This extension is written for revision 2 of the LV2 specification
and is NOT compatible with revisions 3 and later. Do not implement
this extension in new plugins or hosts, and do not expect it to work
in old ones. It is only available here for archaeological purposes."
Even in its short life LV2 has managed to create some archeology.
So AFAICS, there is no GUI extension except the one using a separate
process which does not really scale very well to large numbers of
plugins (and which as Gordon already mentioned is provided in simpler
form by DSSI).
Which leads to my question: if everything can be done by extensions,
as is the recurring mantra, why was whatever revision 3 provides not
implemented as an extension to revision 2 ? Of course this would have
led to the first example of two extensions being mutually incompatible,
something which is a real risk but conveniently ignored in all LV2
propaganda.
Something about how things refer to ports had to be clarified/changed in
the core spec. Unfortunate, but them's the ropes. Extremely unlikely
that something similar happens again (since there isn't much in the core
spec to change in the first place).
The last bit of that argument doesn't make any sense.
Q2.
Would the LV2 consortium accept an extension that would:
Nobody has to "accept" anything.
- if required by a plugin, be the only one, but
unconditionally,
The extension can define this if it wants. They can define anything.
- completely replace LV2's 'base',
including the initialisation
and process calls, the port descriptions in an external file,
and whatever else by some other mechanism ?
I suppose it could. Though why is far beyond me... what's your point?
Such an extension would effectively embed a completely
new
plugin standard into LV2, leaving only the plugin discovery
and packaging mechanism.
... and?
Supporting it would be no more complex than supporting
e.g.
both dynparams and port groups, so there's no technical
rationale for refusing such an extension. There could be an
ideological one of course. But if that is enough to refuse an
extension, then ideological attacks on LV2 are legitimate as
well.
I don't know where you're getting this "accept" and "refuse"
nonsense,
as if there's some LV2 cabal that has to approve everything you do.
This is pretty much completely contrary to the entire point. You want
to attack LV2 by constructing an extension that would be "refused" by
authority? What? The whole point is that this can't happen (though you
yourself have advocated several times that it SHOULD be monolithic and
authoritarian so this kind of crap could happen, so I don't know how you
can possibly try and use this argument now).
Once again, Fons, you criticize what you clearly do not understand,
based on arguments that are pretty much entirely based on said ignorance
(and blatantly in contradiction with others you've made in the past).
Why?
-dr