How to develop guis for LV2?

[Ulrich Lorenz Schlüter]

Hi list,

as the LV2 UI extension is broken, how do I develop a gui for a LV2 plugin.

Thanks

Uli
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[James Warden]

Hi,

take a look at the invada studio LV2 plugin source code.

http://www.invadarecords.com/Downloads.php?ID=00000264

J.

--- On Thu, 10/15/09, Ulrich Lorenz Schlüter <audio-mobster@...> wrote:

> From: Ulrich Lorenz Schlüter <audio-mobster@...>
> Subject: [LAD] How to develop guis for LV2?
> To: "LAD" <linux-audio-dev@...>
> Date: Thursday, October 15, 2009, 5:59 PM
> Hi list,
>
> as the LV2 UI extension is broken, how do I develop a gui
> for a LV2 plugin.
>
> Thanks
>
> Uli
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@...
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

     
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Gordon JC Pearce MM3YEQ]

On Thu, 2009-10-15 at 23:59 +0200, Ulrich Lorenz Schlüter wrote:
> Hi list,
>
> as the LV2 UI extension is broken, how do I develop a gui for a LV2 plugin.
>
> Thanks
>
> Uli

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.

Gordon MM0YEQ

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Patrick Shirkey]

On 11/05/2009 08:48 AM, Gordon JC Pearce wrote:

> On Thu, 2009-10-15 at 23:59 +0200, Ulrich Lorenz Schlüter wrote:
>    
>> Hi list,
>>
>> as the LV2 UI extension is broken, how do I develop a gui for a LV2 plugin.
>>
>> Thanks
>>
>> Uli
>>      
> 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 OP wanted to know about LV2 and you have just trashed it completely.




Patrick Shirkey
Boost Hardware Ltd




_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Jörn Nettingsmeier-6]

Ulrich Lorenz Schlüter wrote:
> Hi list,
>
> as the LV2 UI extension is broken, how do I develop a gui for a LV2 plugin.

great programmers steal: http://nedko.arnaudov.name/soft/lv2fil/trac/
nedko also submitted the external UI extension to ardour, so he's
probably the no.1 expert on external UIs at the moment. btw, the website
is slightly out of date: ardour has had support for external UIs since
2.8.2.

for native gtk UIs, steal from the excellent calf plugin set.

my host of choice is ardour, i can't comment on usability in other
environments, but in ardour, both are great!


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Adrian Knoth]

On Thu, Nov 05, 2009 at 10:17:09AM +0100, Jörn Nettingsmeier wrote:

Hi!

> is slightly out of date: ardour has had support for external UIs since
> 2.8.2.

2.8.3, 2.8.2 only with nedko's patch.


Just my €0.02

--
mail: adi@...   http://adi.thur.de        PGP/GPG: key via keyserver

Windows NT is a scalable operating system that makes the most out of
your server and scales easily to enterprise level. [ ] yes [ ] no
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Wed, 2009-11-04 at 21:48 +0000, Gordon JC Pearce wrote:

> On Thu, 2009-10-15 at 23:59 +0200, Ulrich Lorenz Schlüter wrote:
> > Hi list,
> >
> > as the LV2 UI extension is broken, how do I develop a gui for a LV2 plugin.
> >
> > Thanks
> >
> > Uli
>
> 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.

lol.

-dr


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Thu, 2009-10-15 at 23:59 +0200, Ulrich Lorenz Schlüter wrote:
> Hi list,
>
> as the LV2 UI extension is broken, how do I develop a gui for a LV2 plugin.

It is only "broken" in an academic sense.  It works fine, as it always
has.

-dr


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Fons Adriaensen-2]

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.

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Thu, 2009-11-05 at 22:21 +0100, fons@... 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


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Thu, 2009-11-05 at 22:21 +0100, fons@... wrote:
> 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."

For anyone genuinely interested and not just taking vain pot shots to
further some weird personal vendetta or whatever the hell:

The thing that changed in r3 is: persistent references to ports must
refer to ports by their symbol, and not their index.  Persistent means
things on disk that might refer to several versions of a plugin in the
future, nothing about the index has actually changed.  Plugin data
files, host session files, etc.

The reasoning for this is for things like dynamic plugins or plugin
wrappers, a numeric namespace doesn't work.  For example:

Plugin A has 4 ports
Plugin B has 2 ports

Plugin C is a wrapper that loads both plugin A and plugin B and exposes
their ports.  Number the B ports starting at 4, fine.

What if a new version of plugin A comes out that has 5 ports?  Uh-oh.
The indices of Plugin C have been broken.  Indices are not a
good /persistent/ identifier for this reason (they are fine at run-time
or more generally when the plugin versions are fixed).

Nobody thought of this so the clarification was not in the original
spec.  Though the intention was for indices to be just a runtime
optimization all along, it was never explicitly stated that using
indices for persistent stuff is a bad idea.  Now it is.

Unfortunately the GUI extension does refer to ports by index, so it
needs to be updated, hence the above warning.  This is just a future
proof thing that came up, and in practice nothing is broken and it all
works exactly as it did before.

-dr


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Loki Davison]

>
> 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
>
>
> _______________________________________________
> Linux-audio-dev mailing list
> Linux-audio-dev@...
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
>

I'm pretty sure Fons is occasionally a very smart and effective troll ;)

As a gedankenexperiment what are the problems in LV2 that make it
ineffective or even inelegant for implementing something like Jconv
i.e a wrapper on your very lovely zita-convolver? How should these be
solved?

Loki
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Fri, 2009-11-06 at 12:26 +1100, Loki Davison wrote:
> As a gedankenexperiment what are the problems in LV2 that make it
> ineffective or even inelegant for implementing something like Jconv
> i.e a wrapper on your very lovely zita-convolver? How should these be
> solved?

The main thing lacking for stuff like this is an elegant way of passing
stuff like the filename to the plugin so it can load it.  The "string
ports" extension will work for this though, it's just a bit kludgey
(it's basically a stop-gap).

We need a good message/RPC system, basically, for quite a few things.
Something like OSC but a bit more flexible (or just OSC itself is an
option as well).

-dr


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Fons Adriaensen-2]

On Thu, Nov 05, 2009 at 06:21:03PM -0500, David Robillard wrote:

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

(having read your other post wich outlines the technicalities)

This could have been done as an extension. I agree that would
have created some chaos, so changing the core spec was probably
a wise choice. But that's the point: this can happen at any time
with extensions. If you have N extensions, how big is the chance
that not any subset of S <= N of them will not be in conflict
somehow ? Or depend on things that are specified nowhere, such
as the order in which a host should use them and call any new
extension specific functions in the plugin ? What mechanism is
there in LV2's core spec that ensures that extensions will be
orthogonal to each other, even if written by authors who don't
know each other's work, and evaluated by a host in unspecified
order ?

> Nobody has to "accept" anything.

I'm not going to spend even a minute writing a plugin or
a set of them, requiring maybe five new extensions, if I'm
not absolutely sure that these extensions will be accepted
(that is: implemented) by the authors of the major host
programs, e.g. Ardour. And don't ask me to do that myself.
It would take ages for me to get familiar enough with e.g.
Ardour's internal structures and code to be able to do that.
And even then, the patches would still have to be accepted
by Ardour's core team. And that's only _one_ host, be it an
important one.

Currently I'm designing a rather large app that will rely
a lot on plugins. It will have at least three incompatible
types of them. By incompatible I mean that if the types are
A,B,C, it would be completely pointless to try and insert
e.g. a B where an A is expected and so on. All of them
require _embedded_ GUIs, to the point that a user will
not even be aware that some parts of the app are plugins.
Some of them require quite complex interaction with the
core of the app, not just a set of audio and traditional
control values. Type A could probably be used outside the
app as well, if you strip some its features, for the others
the chances that they can be re-used as plugins are zero.

Should I try and use LV2 for all of this ? It would create
a lot of extra complexity, starting with having to squeeze
everything through a C interface while both sides are C++,
a lot of textual representation of fixed things just adding
overhead, and a collection of extensions that I'm pretty
sure no other host will ever implement. So the answer is
no, unless I missed something.

There are much simpler solutions available. If I define each
of A,B,C as a C++ base class then any .so that provides a
factory for a derived class of any of them is a plugin. And
that's it. Of course this could mean issues with C++ binary
compatibility, but in this case, given that most of this
will never be used elsewhere anyway and distributed as a
single package, I accept those.

Ciao,

--
FA

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Paul Davis]

On Fri, Nov 6, 2009 at 6:08 AM,  <fons@...> wrote:
> This could have been done as an extension. I agree that would
> have created some chaos, so changing the core spec was probably
> a wise choice. But that's the point: this can happen at any time
> with extensions. If you have N extensions, how big is the chance
> that not any subset of S <= N of them will not be in conflict
> somehow ?

fons, although i share some of your concerns about LV2's design
philosophy, I don't think its fair to conflate this particular issue
with extensions at all. there's no evidence here of any "conflict"
between extensions. there was a revision to the core specification,
and it was a fairly deep revision at that, albeit a small one. this
made one (and at this point, it really does look like one) extension
that was written using an older version of the spec now technically
invalid (even though in practice it still works). this could
theoretically happen any time that the core spec is modified, and it
underlines how much more important it is for that to remain stable if
useful functionality is developed in the more "ad hoc distributed" way
that the extension mechanism provides for. but i really don't think it
says *anything* about the extension mechanism at all.

> I'm not going to spend even a minute writing a plugin or
> a set of them, requiring maybe five new extensions, if I'm
> not absolutely sure that these extensions will be accepted
> (that is: implemented) by the authors of the major host
> programs, e.g. Ardour.

having seen the breadth of functionality offered by both VST and AU
plugins, using APIs that in almost all respects provides no more
functionality than LV2 core + some GUI extension, its hard for me to
imagine what extensions you might want to be using in the context of a
general purpose host like ardour. this is a clue:

 >All of them
> require _embedded_ GUIs, to the point that a user will
> not even be aware that some parts of the app are plugins.
> Some of them require quite complex interaction with the
> core of the app, not just a set of audio and traditional
> control values.

Harrison faced precisely this problem with mixbus (if you haven't
noticed this yet, http://mixbus.harrisonconsoles.com/). They decided
to take advantage of the fact that the host is open source and that it
was less productive to try to define a *plugin* API that provided the
required level of interaction with the core of the app. So they just
hacked Ardour's code itself (even though the actual DSP involved is
still in a LADSPA plugin).

> There are much simpler solutions available. If I define each
> of A,B,C as a C++ base class then any .so that provides a
> factory for a derived class of any of them is a plugin. And
> that's it. Of course this could mean issues with C++ binary
> compatibility, but in this case, given that most of this
> will never be used elsewhere anyway and distributed as a
> single package, I accept those.

your preferred solution depends, fundamentally, on how much you
*really* want some/all of those plugins to be re-usable. To take the
Harrison case as an example, again: the plugin in that case is
fundamentally *not* reusable outside of mixbus, even though its using
an API that isn't ardour specific. if you *really* want your "type A"
plugins to be reusable in other contexts, then *of course* you would
develop them using a non-host specific API. LV2 might be highly
appropriate for that, or not. But if you don't really care about that
reuse, then of course your common, host specific API makes more sense
and is less work.

so, i don't really see this as having much to do with LV2, its current
state or its design philosophy. i'd also note that while i too have
been critical of LV2's design, i don't see anything else that can move
us past the state of affairs that LADSPA represents. to the extent
that the future of open source cross-host audio plugins, at least for
linux, requires such an API, i think that LV2 is it. it does need some
"social engineering" (i think that this is what jorn called it), but
thats entirely different from postulating that the extension-based
design is fundamentally flawed.

--p
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Steve Harris-12]

On 5 Nov 2009, at 23:33, David Robillard wrote:

> On Thu, 2009-11-05 at 22:21 +0100, fons@... wrote:
>> 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."
>
> For anyone genuinely interested and not just taking vain pot shots to
> further some weird personal vendetta or whatever the hell:
>
> The thing that changed in r3 is: persistent references to ports must
> refer to ports by their symbol, and not their index.  Persistent means
> things on disk that might refer to several versions of a plugin in the
> future, nothing about the index has actually changed.  Plugin data
> files, host session files, etc.

This was a hangover from LADSPA, which had confusing and contradictory  
claims about what should/shouldn't be used to identify ports.

I still don't think there's consensus there.

- Steve
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[Fons Adriaensen-2]

On Fri, Nov 06, 2009 at 12:26:40PM +1100, Loki Davison wrote:

> I'm pretty sure Fons is occasionally a very smart and effective troll ;)

Noted.
 
> As a gedankenexperiment what are the problems in LV2 that make it
> ineffective or even inelegant for implementing something like Jconv
> i.e a wrapper on your very lovely zita-convolver? How should these be
> solved?

I'm not going to spend time answering questions of who
calls me a troll.

Ciao,

--
FA

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[rosea]

fons@... wrote:

> On Fri, Nov 06, 2009 at 12:26:40PM +1100, Loki Davison wrote:
>
>  
>> I'm pretty sure Fons is occasionally a very smart and effective troll ;)
>>    
> I'm not going to spend time answering questions of who
> calls me a troll.
>
> Ciao,
>
>  

I think you also have to read the ;)

For everyone taking part into this discussion:
A discussion about such an important subject as LAD plugins, deserves to
be far more straight and 'to the point' imho. Just keep it technical,
use arguments and keep blaming, yelling and picking out of it. At the
end that's not beneficial  for any of us.

\r


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Fri, 2009-11-06 at 12:08 +0100, fons@... wrote:

> On Thu, Nov 05, 2009 at 06:21:03PM -0500, David Robillard wrote:
>
> > 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).
>
> (having read your other post wich outlines the technicalities)
>
> This could have been done as an extension. I agree that would
> have created some chaos, so changing the core spec was probably
> a wise choice.

How could changing the rules about how anything references ports be done
as an extension?

The point of the change is that referring to indices makes things break.
It has to be defined in the core to prevent this.  It is associated with
versioning.  There are the sort of (very few) things that are, and must
be, defined in the core.  It is not so much a breakage specific to the
GUI extension as an oversight that has now been resolved.

>  But that's the point: this can happen at any time
> with extensions. If you have N extensions, how big is the chance
> that not any subset of S <= N of them will not be in conflict
> somehow ?

... What extensions are in conflict?  FUD FUD FUD

>  Or depend on things that are specified nowhere, such
> as the order in which a host should use them and call any new
> extension specific functions in the plugin ?

This doesn't really make any sense.

>  What mechanism is
> there in LV2's core spec that ensures that extensions will be
> orthogonal to each other, even if written by authors who don't
> know each other's work, and evaluated by a host in unspecified
> order ?

This also makes no sense.  It might be possible to deliberately
construct a really, really, really cracked out extension that would
somehow be in "conflict" with another, but I can't even come up with
such a case.  I'd say the chance of this happening with extensions that
aren't deliberately written to do this is extremely close to 0.  Even in
this overwhelmingly unlikely case, if conflicting extensions existed it
simply would not make sense to implement them both in a single plugin.
Big deal.

Maybe if you can come up with an example of such "conflicting"
extensions...

> > Nobody has to "accept" anything.
>
> I'm not going to spend even a minute writing a plugin or
> a set of them, requiring maybe five new extensions, if I'm
> not absolutely sure that these extensions will be accepted
> (that is: implemented) by the authors of the major host
> programs, e.g. Ardour. And don't ask me to do that myself.
> It would take ages for me to get familiar enough with e.g.
> Ardour's internal structures and code to be able to do that.
> And even then, the patches would still have to be accepted
> by Ardour's core team. And that's only _one_ host, be it an
> important one.

Fine then, don't.  Nobody says you have to do anything.  You not wanting
to do stuff is certainly is not an argument against LV2.

> Currently I'm designing a rather large app that will rely
> a lot on plugins. It will have at least three incompatible
> types of them. By incompatible I mean that if the types are
> A,B,C, it would be completely pointless to try and insert
> e.g. a B where an A is expected and so on. All of them
> require _embedded_ GUIs, to the point that a user will
> not even be aware that some parts of the app are plugins.
> Some of them require quite complex interaction with the
> core of the app, not just a set of audio and traditional
> control values. Type A could probably be used outside the
> app as well, if you strip some its features, for the others
> the chances that they can be re-used as plugins are zero.
>
> Should I try and use LV2 for all of this ?

Lucky for you, because of the extension mechanism you ironically seem to
hate, you can :)

>  It would create
> a lot of extra complexity, starting with having to squeeze
> everything through a C interface while both sides are C++,

(see below)

> a lot of textual representation of fixed things just adding
> overhead

This is true, but the benefits are substantial, it's not "just" adding
overhead.  Extensions could be invented to avoid (most of) the text part
entirely, but that's a lot of work for little gain.  I'd rather just
deal with that overhead as it comes up.

> , and a collection of extensions that I'm pretty
> sure no other host will ever implement.

What would these extensions be?  And would they be mandatory for the
plugins working whatsoever?

>  So the answer is
> no, unless I missed something.

All this is pretty much the cost of using a generic plugin mechanism.
If you want them to work elsewhere, then yes, you should.  Otherwise,
they won't.  If these needed extensions are absolutely necessary for the
plugins to be in any way useful, and very non-generic and not likely to
be implemented elsewhere, then the plugins are inherently not useful in
general, LV2 or no LV2.  This is pretty unlikely though.

> There are much simpler solutions available. If I define each
> of A,B,C as a C++ base class then any .so that provides a
> factory for a derived class of any of them is a plugin. And
> that's it. Of course this could mean issues with C++ binary
> compatibility, but in this case, given that most of this
> will never be used elsewhere anyway and distributed as a
> single package, I accept those.

You can use C++ in an extension if you like.  Such an extension would be
trivial, e.g. "the extension_data method on a plugin, called with this
URI, returns an object of this type".  Might piss off some of the pure C
people, but whatever.  It's better to have LV2 plugins that (can) work
in any C++ host than no plugins that work elsewhere at all.

That said, it's certainly better to use C if possible...

-dr


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

[David Robillard-3]

On Fri, 2009-11-06 at 07:17 -0500, Paul Davis wrote:
> there was a revision to the core specification,
> and it was a fairly deep revision at that, albeit a small one. this
> made one (and at this point, it really does look like one) extension
> that was written using an older version of the spec now technically
> invalid (even though in practice it still works). this could
> theoretically happen any time that the core spec is modified, and it
> underlines how much more important it is for that to remain stable if
> useful functionality is developed in the more "ad hoc distributed" way
> that the extension mechanism provides for.

Definitely.  It was not done lightly :)

This was really sort of a special case since it had to do with
identifiers and versioning.  I would be very surprised if anything like
it has to happen again.

> so, i don't really see this as having much to do with LV2, its current
> state or its design philosophy. i'd also note that while i too have
> been critical of LV2's design, i don't see anything else that can move
> us past the state of affairs that LADSPA represents.

<insert obligatory GMPI joke here>

-dr


_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@...
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev