[LAD] How to develop guis for LV2?

[fons at kokkinizita.net]

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.


Q2.

Would the LV2 consortium accept an extension that would:

- if required by a plugin, be the only one, but unconditionally,

- 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 ?

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
well.

Ciao,

-- 
FA

Io lo dico sempre: l'Italia è troppo stretta e lunga.