[LAD] How to develop guis for LV2?
dave at drobilla.net
Thu Nov 5 23:21:03 UTC 2009
On Thu, 2009-11-05 at 22:21 +0100, fons at 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).
> 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
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.
> 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.
> 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
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).
More information about the Linux-audio-dev