[LAD] How to develop guis for LV2?

Hi list,

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

Thanks

Uli

James Warden

2009-10-16 07:47:58 UTC

Hi,

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

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

J.

Subject: [LAD] How to develop guis for LV2?
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
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Gordon JC Pearce

2009-11-04 21:48:01 UTC

Post by 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

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

Patrick Shirkey

2009-11-05 02:18:53 UTC

Post by Gordon JC Pearce

Post by 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

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

f***@kokkinizita.net

2009-11-05 21:21:34 UTC

Post by Patrick Shirkey

Post by Gordon JC Pearce
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.

David Robillard

2009-11-05 23:21:03 UTC

Post by Patrick Shirkey

Why do you always say such inflamatory remarks like this?

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.

Post by f***@kokkinizita.net
Q2.

Nobody has to "accept" anything.

Post by f***@kokkinizita.net
- if required by a plugin, be the only one, but unconditionally,

The extension can define this if it wants. They can define anything.

Post by f***@kokkinizita.net
- 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?

Post by f***@kokkinizita.net
Such an extension would effectively embed a completely new
plugin standard into LV2, leaving only the plugin discovery
and packaging mechanism.

... and?

Post by f***@kokkinizita.net
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

Loki Davison

2009-11-06 01:26:40 UTC

I suppose it could. Though why is far beyond me... what's your point?

Post by f***@kokkinizita.net
Such an extension would effectively embed a completely new
plugin standard into LV2, leaving only the plugin discovery
and packaging mechanism.

... and?

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

David Robillard

2009-11-06 01:32:47 UTC

Post by Loki Davison
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

Simon Burton

2009-11-11 05:18:14 UTC

On Thu, 05 Nov 2009 20:32:47 -0500

Post by David Robillard
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).

dbus ?

David Robillard

2009-11-11 15:42:57 UTC

Post by Simon Burton
On Thu, 05 Nov 2009 20:32:47 -0500

Post by David Robillard
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).

dbus ?

No, I just mean a message format for sending to plugins / UIs / etc, not
a system level thing.

Think OSC, or messages in pd/Max, etc

-dr

David Aguilar

2009-11-12 06:39:17 UTC

Post by Simon Burton
On Thu, 05 Nov 2009 20:32:47 -0500

Post by David Robillard
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).

dbus ?

No, I just mean a message format for sending to plugins / UIs / etc, not
a system level thing.
Think OSC, or messages in pd/Max,

json is great. If you need binary rpc then take a look at bert. They
could be good mediums for simple language-neutral data exchange.

David Robillard

2009-11-12 14:58:13 UTC

Post by David Aguilar

Post by Simon Burton
On Thu, 05 Nov 2009 20:32:47 -0500

Post by David Robillard
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).

dbus ?

No, I just mean a message format for sending to plugins / UIs / etc, not
a system level thing.
Think OSC, or messages in pd/Max,

json is great.

never thought of using it, but using json is a good idea if (it ends up
fitting with whatever abstract data model we need, anyway). Syntax(es)
should be independent of the actual spec though, IMO.

Post by David Aguilar
If you need binary rpc then take a look at bert. They
could be good mediums for simple language-neutral data exchange.

this is interesting, I hadn't seen this before. many of the lengths are
only two bytes though, which is a bit of a severe limitation

I'll think about how this can all mesh together...

Thanks

-dr

f***@kokkinizita.net

2009-11-06 13:36:31 UTC

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

Noted.

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.

rosea grammostola

2009-11-06 14:00:10 UTC

Post by Loki Davison
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

David Robillard

2009-11-06 16:02:19 UTC

Post by rosea grammostola
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

Seriously. The amount of completely baseless hand-wavey FUD nonsense
that flies around this subject absolutely blows my mind...

-dr

f***@kokkinizita.net

2009-11-06 11:08:30 UTC

Post by David Robillard
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 ?

Post by David Robillard
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.

Paul Davis

2009-11-06 12:17:51 UTC

Post by f***@kokkinizita.net
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.

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

Post by f***@kokkinizita.net
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).

Post by f***@kokkinizita.net
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

David Robillard

2009-11-06 16:00:33 UTC

Post by Paul Davis
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.

Post by Paul Davis
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

David Robillard

2009-11-06 15:55:17 UTC

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.

Post by f***@kokkinizita.net
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

Post by f***@kokkinizita.net
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.

Post by f***@kokkinizita.net
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...

Post by David Robillard
Nobody has to "accept" anything.

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.

Post by f***@kokkinizita.net
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 :)

Post by f***@kokkinizita.net
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)

Post by f***@kokkinizita.net
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.

Post by f***@kokkinizita.net
, 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?

Post by f***@kokkinizita.net
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.

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

f***@kokkinizita.net

2009-11-06 17:27:53 UTC

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

By doing it the new way if the extension is requested,
and the old way otherwise.

Post by David Robillard
... What extensions are in conflict? FUD FUD FUD

Can you name two LAD members with the same birthday ?
Probably not, but if you put 23 of them in a room the
chances are 50% there will be two. At the moment there
are few extensions, so probably there's no conflict.

Post by f***@kokkinizita.net
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.

Doesn't it ? If a host has to consider all active
extensions as a whole then the number of possible
combinations explodes. If it considers them one by
one, doing what is required for extension A could
easily have an impact on extension B, if both are
about similer things, e.g. ports. For this reason
a host author could decide to do first B then A, if
that solves his problem. At the same time a plugin
author could assume (even without been aware of
this) that the order has to be A then B.

Prove it.

Post by David Robillard
Even in
this overwhelmingly unlikely case, if conflicting extensions existed it
simply would not make sense to implement them both in a single plugin.

The whole idea of a plugin system is that host and plugins can be
developed separately. This requires that all parts of the API,
*including their possible interactions and dependencies* are
either well-defined, or guaranteed by design not to interfere
with each other.

Post by f***@kokkinizita.net
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.

Right.

Post by David Robillard
Nobody says you have to do anything.

That's valid for anything in FOSS. Still I'm doing things.

Post by David Robillard
You not wanting to do stuff is certainly is not an argument
against LV2.

Having one potential plugin author less means a (small) impact
on its acceptance. It's not a technical argument, that's true.

Post by f***@kokkinizita.net
...
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 :)

I don't hate it. I just remember the complete chaos that
resulted from uncoordinated ad-hoc extensions to HTML, before
the mess was more or less cleaned up.

Post by f***@kokkinizita.net
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)

Post by f***@kokkinizita.net
a lot of textual representation of fixed things just adding
overhead

I'd rather not. And this has nothing to do with ease of
development, or overhead in the sense that I takes more
of my time. My opinion would not change even if a perfect
SDK would hide all the dirty details and overhead.
The final result is what should be no be more complex
than required.

Post by f***@kokkinizita.net
, 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?

I wouldn't require them otherwise.

Post by David Robillard
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".

The extreme case of this is what I proposed in my Q2 earlier.
That object could take over the complete API, and in many
cases that would be the simplest solution.

Post by David Robillard
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.

Ciao,

--
FA

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

David Robillard

2009-11-07 17:52:52 UTC

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

By doing it the new way if the extension is requested,
and the old way otherwise.

This would not solve the problem because hosts need to follow the rules
too. The core spec obviously has to specify things like how to refer to
ports correctly. There are a small number of things that need to be
defined in the core spec for obvious reasons, this is one of them.

Post by David Robillard
... What extensions are in conflict? FUD FUD FUD

This presumes that extensions "conflicting" makes sense, or is likely to
happen.

Post by f***@kokkinizita.net
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.

Why? Says who? Example?

Post by f***@kokkinizita.net
, if both are
about similer things, e.g. ports. For this reason
a host author could decide to do first B then A, if
that solves his problem. At the same time a plugin
author could assume (even without been aware of
this) that the order has to be A then B.

I don't know what this "order" stuff means at all. Extensions don't
have an order.

Prove it.

Extensions are usually either new port types, which can't conflict with
anything, or newly added functions, which can't conflict with anything
either.

The only kind of extension that could "conflict" is what that redefines
the semantics of something very fundamental in the core spec, which is
silly, and again, even if such an extension existed, it doesn't matter,
because that one particular weird extension might not make sense with
such and such a host/plugins/extension/whatever. So? If it's
fundamentally incapable of working in some setup, then it won't.

You are making the outrageous claim, the burden of proof is on you.

Post by David Robillard
Even in
this overwhelmingly unlikely case, if conflicting extensions existed it
simply would not make sense to implement them both in a single plugin.

Again, what interactions and dependencies? You're waving your hands
around screaming about "conflict" with no example or argument to suggest
such conflict is likely or even possible.

Is isn't, and furthermore, if it did happen it's not a big dealer, and
furtherfurthermore, the community would take care of this anyway (why
would anyone do this without a good reason? and if they did, why would
anyone implement it?)

Here is an actual example of the sort of way extensions might
"conflict": Extension A says the block size passed to the process method
must be always 1. Extension B says the block size passed to the process
method must be always 512. These extensions "conflict". So what? You
can't do both on the same plugin, obviously. The things they describe
inherently "conflict". This is simply not a problem.

If you think it is a problem, then come up with an example for why. I
can't think of one.

Post by David Robillard
You not wanting to do stuff is certainly is not an argument
against LV2.

Having one potential plugin author less means a (small) impact
on its acceptance. It's not a technical argument, that's true.

Maybe, and everyone would like as many plugins as possible, but you
don't have any concrete reasons. I'd love to address your concerns, but
you don't have any actual concerns. One can not make a patch for FUD.

Why should you even care if this "conflicting" thing is possible anyway?
Will it affect your plugins? Obviously not, you couldn't implement
"conflicting" extensions on a single set of plugins anyway, by
definition.

Post by f***@kokkinizita.net
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 :)

I don't hate it. I just remember the complete chaos that
resulted from uncoordinated ad-hoc extensions to HTML, before
the mess was more or less cleaned up.

A better analogy would be well-formed XML or RDF, where things can
easily be added but it doesn't break anything because the technology has
been designed specifically to handle this; or my shared library analogy
from earlier.

Post by f***@kokkinizita.net
a lot of textual representation of fixed things just adding
overhead

Having the data separate from the code is pretty much "required" to get
all the things we want anyway. Is it more complex than is "required"?
Maybe. It depends how you feel like conveniently defining "complex".
Having an equivalently powerful data model defined in the code somehow
is hardly free either. A vague notion of "complex" doesn't really
matter much when there are tangible advantages/disadvantages to take
into consideration.

Post by f***@kokkinizita.net
, 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?

I wouldn't require them otherwise.

A lot of functionality can be implemented such that the plugin works
without it. You don't /have/ to "require" them.

The extreme case of this is what I proposed in my Q2 earlier.
That object could take over the complete API, and in many
cases that would be the simplest solution.

This wouldn't be an LV2 plugin at all.

-dr

Gabriel M. Beddingfield

2009-11-07 21:37:08 UTC

Post by David Robillard
A better analogy would be well-formed XML or RDF, where things can
easily be added but it doesn't break anything because the technology has
been designed specifically to handle this; or my shared library analogy
from earlier.

<rant>
Except when you want your XHTML (1.1)+MathML (v3)+SVG (1.1)+CSS (Level
3)+XSLT (1.0)+Javascript content to work as expected in everyone's
browser. It doesn't break in the sense that babies aren't
dying... but it doesn't *work*, either. Manwhile the hapless user
with IE6 is thinking, "Why doesn't this stuff work?? It's just a web
page! Microsoft's site looks fine... so it must be /them/."

Hell, even if you stick to HTML 4.0 + CSS 1... you <blink>still</blink>
have to find workarounds for IE 6.
</rant>

FWIW, I think XML is awesome... but this part grates on my nerves.

I think LV2 looks awesome, too... but I can't get a grip on this...

THE PROBLEM: I *want* to write a host that can load anyone's LV2 synth
and FX... and it just works. I want to write synths and FX that will work
in anyone's host.[5] Where do I start?

Looking over the docs... it looks like a host has to support nearly every
extension listed on the wiki[1] if I want to accomplish this. The more I
dig in... and the more I read David's comments... the more that this
appears to be the case. And if something gets added to the list, looks
like I'll have to update my host to support it.

I know of two synths, zyn[3] and linuxsampler[4]. Zyn requires rtmempool
and wants dynparam. LinuxSampler wants hardRtCapable (whatever that is)
and saverestore. I can't find mention of EventPort or MidiEvent in the
RDF files -- but I'm sure those are necessary, too (since they're synths).

Meanwhile, I know of one LV2 host for synths, zynjacku.[2] I have no idea
which extensions it supports... except that I know it supports whatever
zyn has (because it appears Nedko did them together). So, if I write a
synth that requires URI Map -- I don't know if it will work with zynjacku
without digging into source code or bugging Nedko about it.

Then, Lars's tutorial appears to be using his own portgroups extension, as
well as some kind of namespace extension, and I'm not sure if he's using
Midi Port or Midi Event. I have no idea if his examples will work in
zynjacku without compiling them and trying it.

And this is before considering GUI extensions....

Looking at this, people say, "This is good, but it's kind of a mess at the
moment. Can we get some sort of 'canonical list of extensions' or
/something/ stable for devs to work from?" To which Dave replies, "FUD!
FUD! FUD! Such a list accomplishes nothing!"

Am I just missing it, or what? What's the solution to "The Problem"? Is
there core infrastructure (critical extensions) still missing or
something? I'm _really_ willing to help, but so far every idea that I've
put forth has been shot down... and Dave *seems* to think that "The
Problem" isn't a problem.

Thanks,
Gabriel

[1] http://lv2plug.in/docs/index.php?title=Main_Page
[2] http://home.gna.org/zynjacku/
[3] aka "zynadd" http://home.gna.org/zyn/
[4] Version 1.0 at least includes an LV2 version.
[5] Yes, I know there's cases where you have something that is
so application-specific that you can't always do this. I
think it's really cool that LV2 is extensible so that you
can work around it.

Patrick Shirkey

2009-11-08 02:55:05 UTC

Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?

I again ask for submissions. Even if we just have one template that we
can agree on it won't be that much effort to port it across to the other
languages that we would like to have supporting LV2. that will make
things that much clearer for developers across the board.

The standard in the closed source world is to provide a package with the
example code in place add some descriptive comments and a web accessible
howto and we are good to go.

Post by Gabriel M. Beddingfield
Looking over the docs... it looks like a host has to support nearly every
extension listed on the wiki[1] if I want to accomplish this. The more I
dig in... and the more I read David's comments... the more that this
appears to be the case. And if something gets added to the list, looks
like I'll have to update my host to support it.
I know of two synths, zyn[3] and linuxsampler[4]. Zyn requires rtmempool
and wants dynparam. LinuxSampler wants hardRtCapable (whatever that is)
and saverestore. I can't find mention of EventPort or MidiEvent in the
RDF files -- but I'm sure those are necessary, too (since they're synths).
Meanwhile, I know of one LV2 host for synths, zynjacku.[2] I have no idea
which extensions it supports... except that I know it supports whatever
zyn has (because it appears Nedko did them together). So, if I write a
synth that requires URI Map -- I don't know if it will work with zynjacku
without digging into source code or bugging Nedko about it.
Then, Lars's tutorial appears to be using his own portgroups extension, as
well as some kind of namespace extension, and I'm not sure if he's using
Midi Port or Midi Event. I have no idea if his examples will work in
zynjacku without compiling them and trying it.

It's clear that we need to better define the plugin publishing and
dependency system for LV2?

We need a more transparent way of referencing an extension/plugin by to
it's dependencies.

Post by Gabriel M. Beddingfield
And this is before considering GUI extensions....
Looking at this, people say, "This is good, but it's kind of a mess at the
moment. Can we get some sort of 'canonical list of extensions' or
/something/ stable for devs to work from?" To which Dave replies, "FUD!
FUD! FUD! Such a list accomplishes nothing!"
Am I just missing it, or what? What's the solution to "The Problem"? Is
there core infrastructure (critical extensions) still missing or
something? I'm _really_ willing to help, but so far every idea that I've
put forth has been shot down... and Dave *seems* to think that "The
Problem" isn't a problem.
Thanks,
Gabriel
[1] http://lv2plug.in/docs/index.php?title=Main_Page
[2] http://home.gna.org/zynjacku/
[3] aka "zynadd" http://home.gna.org/zyn/
[4] Version 1.0 at least includes an LV2 version.
[5] Yes, I know there's cases where you have something that is
so application-specific that you can't always do this. I
think it's really cool that LV2 is extensible so that you
can work around it.
_______________________________________________
Linux-audio-dev mailing list
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev

Gabriel M. Beddingfield

2009-11-08 04:31:58 UTC

Post by Patrick Shirkey
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?

I don't think so. ATM, there's plenty of high-quality reference code...
especially with Lars's tutorial. This is a different issue.

Post by Patrick Shirkey
It's clear that we need to better define the plugin publishing and
dependency system for LV2?

Not quite (though that would be a Good Thing).

More like a standard that says something like......

FOR SYNTH HOSTS:
----------------

If you follow these guidelines, you may call yourself an "LV2 Synth Host"
and you will be able to work cleanly with every synth that calls itself an
"LV2 Synth Plugin."

+ Support (at least) extensions A, B, and C.
+ The synths will have several MIDI input ports (for note data)
and several audio output ports.
+ All configuration will be done with the events extension.
+ All feedback will be done with the events extension.
+ The plugins may provide a GUI interface. Its width will be
200, 400, 600, or 800 pixels. Its height will be a multiple
of 100 pixels.

FOR SYNTH PLUGINS:
------------------

If you follow these guidelines, you may call yourself an "LV2 Synth
Plugin" and you will be able to work cleanly with every host that calls
itself an "LV2 Synth Host."

+ Freely use extensions A, B, and C. If you use any extra
LV2 extensions, try to make them optional. Otherwise,
please simply call yourself an "LV2 Plugin," because you
won't work with every LV2 Synth Host.
+ Provide several MIDI in-ports for note data, and several
audio out-ports.
+ All configuration will be done with the events extension.
(This does not prohibit you from also doing the same over MIDI)
+ All feedback will be done with the events extension.
+ You are encouraged to create a GUI for your plugin. Its
width shall be 200, 400, 600, or 800 pixels. Its height
shall be a multiple of 100 pixels.

Would somthing like this be *so* bad? There's still room for innovation.
There's still room for plugin authors and host authors to get together and
say, "We all want to start supporting extension D." And that would still
be cool because all the old plugins will still work.

-gabriel

Patrick Shirkey

2009-11-08 05:04:30 UTC

Post by Patrick Shirkey
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?

I don't think so. ATM, there's plenty of high-quality reference
code... especially with Lars's tutorial. This is a different issue.

Is it just me that feels that the existing examples are too obscure and
set the entry level too high for the average developer as well as miss
out important use cases specific to different languages?

On another tangent is LV2 supposed to be a new standard and therefore
provide an accessible documentation codebase for all potential users or
is LV2 designed as a theoretical system which only advanced developers
are given insight into and the rest have to fend for themselves.

Post by Patrick Shirkey
It's clear that we need to better define the plugin publishing and
dependency system for LV2?

Not quite (though that would be a Good Thing).

What you have written below could also be considered a definition of a
set of rules for publishing and specifying dependencies. However it
doesn't completely address the dependency issue. Even if this standard
was followed how would we define the categories such as "LV2 Synth
Plugin"? Is that something that would be handled as someone else has
suggested on a yearly basis by a committee?

Post by Gabriel M. Beddingfield
More like a standard that says something like......
----------------
If you follow these guidelines, you may call yourself an "LV2 Synth
Host" and you will be able to work cleanly with every synth that calls
itself an "LV2 Synth Plugin."
+ Support (at least) extensions A, B, and C.
+ The synths will have several MIDI input ports (for note data)
and several audio output ports.
+ All configuration will be done with the events extension.
+ All feedback will be done with the events extension.
+ The plugins may provide a GUI interface. Its width will be
200, 400, 600, or 800 pixels. Its height will be a multiple
of 100 pixels.
------------------
If you follow these guidelines, you may call yourself an "LV2 Synth
Plugin" and you will be able to work cleanly with every host that
calls itself an "LV2 Synth Host."
+ Freely use extensions A, B, and C. If you use any extra
LV2 extensions, try to make them optional. Otherwise,
please simply call yourself an "LV2 Plugin," because you
won't work with every LV2 Synth Host.
+ Provide several MIDI in-ports for note data, and several
audio out-ports.
+ All configuration will be done with the events extension.
(This does not prohibit you from also doing the same over MIDI)
+ All feedback will be done with the events extension.
+ You are encouraged to create a GUI for your plugin. Its
width shall be 200, 400, 600, or 800 pixels. Its height
shall be a multiple of 100 pixels.
Would somthing like this be *so* bad? There's still room for
innovation. There's still room for plugin authors and host authors to
get together and say, "We all want to start supporting extension D."
And that would still be cool because all the old plugins will still work.
-gabriel

Gabriel M. Beddingfield

2009-11-08 17:30:19 UTC

Hi Patrick,

Post by Patrick Shirkey
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?

I don't think so. ATM, there's plenty of high-quality reference code...

[snip]

Is it just me that feels that the existing examples are too obscure and set
the entry level too high for the average developer as well as miss out
important use cases specific to different languages?

Let me clearify.... I think this would be excellent. However, I don't
think it directly relates to the specific problem I was talking about...
which is a concensus about what extensions hosts should support (as a
minimum) and which ones plugins should limit themselves to so that
everything *works* together.

-gabriel

David Robillard

2009-11-08 18:58:56 UTC

Post by Gabriel M. Beddingfield
Hi Patrick,

Post by Patrick Shirkey
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?

I don't think so. ATM, there's plenty of high-quality reference code...

[snip]

Is it just me that feels that the existing examples are too obscure and set
the entry level too high for the average developer as well as miss out
important use cases specific to different languages?

Plugins should use whatever extensions they please. Plugins should
under no circumstances /require/ extensions unless it is absolutely
necessary to do so for the plugin to work at all. Given this, there is
little need to "limit" yourself. Necessity is necessity, regardless of
what the house judiciary committee on LV2 extension support decides
people "should" implement ;)

Easy documentation about which hosts support what is indeed useful, but
you can't come up with a "consensus" about what hosts "should" support.
They "should" support everything ;)

It's what they DO support that matters. There's been far, far, far too
much yapping about this on the list at this point. Yes, we need a
compatibility matrix or something along those lines. Everyone agrees.
There is really no need to continually state it.

SOMEONE MAKE ONE ON THE DAMNED WIKI THEN

The problem is simply a lack of documentation. The solution is to write
it. There is certainly no utility in complaining about these problems
at this point. "Those who can do, those who can't complain".

Since there seem to be several people who are really, really into this
problem.... solve it already. Using mediawiki is not difficult.

-dr

Nedko Arnaudov

2009-11-08 19:24:48 UTC

Post by David Robillard
Easy documentation about which hosts support what is indeed useful, but
you can't come up with a "consensus" about what hosts "should" support.
They "should" support everything ;)
It's what they DO support that matters. There's been far, far, far too
much yapping about this on the list at this point. Yes, we need a
compatibility matrix or something along those lines. Everyone agrees.
There is really no need to continually state it.
SOMEONE MAKE ONE ON THE DAMNED WIKI THEN
The problem is simply a lack of documentation. The solution is to write
it. There is certainly no utility in complaining about these problems
at this point. "Those who can do, those who can't complain".
Since there seem to be several people who are really, really into this
problem.... solve it already. Using mediawiki is not difficult.

IMO, it is much more appropriate to provide this information primary at
the plugin/host web sites. Providing it at lv2plug.in site is nice but I
doubt it will be the place where ppl will look first. Also please note
that this can be integrated at apps.linuxaudio.org.

IMHO, the two basic questions that user will have are:

1. Will the plugin X that I use a lot work on host Y that I want to try?
2. Will the host W that I use a lot work well with the plugin Z I've found?

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

David Robillard

2009-11-08 19:39:19 UTC

Well, there are certainly a lot of people complaining about it, so that
suggests the plugin authors /aren't/ doing it. Somebody has to.

The wiki provides a way for those prone to whining to actually do
something about it. A central overview of the state of compatibility
would be useful anyway, and seems to be largely what people are asking
for. If the information was spread all over the place there would be
much less utility for people looking for which extensions it is wisest
to use (e.g. Gabriel).

IMO 99.99% of these complaints are really just about people going to
lv2plug.in looking for information and finding a big random pile of
inconsistent crap. People seem to like to extrapolate this to some kind
of argument about the technology, but they are wrong. There needs to be
a good, coherent, and consistent source of documentation for things LV2,
to address these concerns.

I am dealing with this problem as far as extensions goes, but not the
"what supports what" stuff.

New idea: it is tempting to define a very simple turtle document format
for hosts to signify what they support, then this kind of compatibility
information could be automatically generated as well (and in a much more
useful form than a human could put together). The information is
already there for plugins. As far as I'm concerned the lack of
automatically generated documentation (and/or machine readable data in
general) is pretty much the sole reason for every single complaint
related to this whole thing. This way is also decentralized, but the
results for all "known" implementations could be hosted at lv2plug.in
(or anywhere else) for convenience.

I am surprised I didn't think of this before, but it seems to be a
pretty good idea. All that is needed as far as maintenance goes is for
hosts to supply a simple turtle document that says "I implement foo and
bar and baz extensions". The rest can be compiled into whatever fancy
human readable form you want, for every single plugin out there, by a
tool. If I provide a template, would anyone be willing to put together
these documents? I will gladly write the tool if the data is there, and
the problem will be solved, and a convention set that solves it in the
future with basically no effort involved.

Post by Nedko Arnaudov
1. Will the plugin X that I use a lot work on host Y that I want to try?
2. Will the host W that I use a lot work well with the plugin Z I've found?

3. How "well supported" is this extension, and should I use it in my new
plugin?

This question needs an overview. Even if plugin and host authors supply
this information, an overview is useful.

-dr

Nedko Arnaudov

2009-11-08 19:46:37 UTC

Post by David Robillard
New idea: it is tempting to define a very simple turtle document format
for hosts to signify what they support, then this kind of compatibility
information could be automatically generated as well (and in a much more
useful form than a human could put together). The information is
already there for plugins. As far as I'm concerned the lack of
automatically generated documentation (and/or machine readable data in
general) is pretty much the sole reason for every single complaint
related to this whole thing. This way is also decentralized, but the
results for all "known" implementations could be hosted at lv2plug.in
(or anywhere else) for convenience.
I am surprised I didn't think of this before, but it seems to be a
pretty good idea. All that is needed as far as maintenance goes is for
hosts to supply a simple turtle document that says "I implement foo and
bar and baz extensions". The rest can be compiled into whatever fancy
human readable form you want, for every single plugin out there, by a
tool. If I provide a template, would anyone be willing to put together
these documents? I will gladly write the tool if the data is there, and
the problem will be solved, and a convention set that solves it in the
future with basically no effort involved.

I've been thinking about this for a while and IMHO, it is best to put it
in the DOAP. OTOH, when things change they do change. And what user
really cares is whether plugin and host are compatible in the versions
that are supplied by their distro.

Post by Nedko Arnaudov
1. Will the plugin X that I use a lot work on host Y that I want to try?
2. Will the host W that I use a lot work well with the plugin Z I've found?

3. How "well supported" is this extension, and should I use it in my new
plugin?
This question needs an overview. Even if plugin and host authors supply
this information, an overview is useful.

This is where user comments come. Some distros can assign comments to
packages, I've seen this in Arch, when I tried it recently.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

David Robillard

2009-11-08 20:25:12 UTC

I've been thinking about this for a while and IMHO, it is best to put it
in the DOAP. OTOH, when things change they do change.

Mosts hosts don't even have RDF metadata. DOAP is just one vocabulary,
I agree it should be shipped with hosts though, and all data should
probably be in the same document (doap stuff, supported extensions,
whatever else). This would be a good precedent to set.

Post by Nedko Arnaudov
And what user
really cares is whether plugin and host are compatible in the versions
that are supplied by their distro.

This is another reason for automatically generating it. Considering all
the versions, and all the permutations of hosts/plugins, doing it as a
human maintained static set of documents isn't really feasible.

Post by Nedko Arnaudov
1. Will the plugin X that I use a lot work on host Y that I want to try?
2. Will the host W that I use a lot work well with the plugin Z I've found?

3. How "well supported" is this extension, and should I use it in my new
plugin?
This question needs an overview. Even if plugin and host authors supply
this information, an overview is useful.

This is where user comments come. Some distros can assign comments to
packages, I've seen this in Arch, when I tried it recently.

The point is that having this stuff scattered all over the place doesn't
really solve the problem. We need to establish a standard format for
this data, gather the data (in a distro-agnostic format (RDF)), write
the tools, and get it done. People can package the results and
integrate it with whatever other things as they please.

Integration with packaging systems might be nice (for people that use
those distros) but doesn't solve the problem. First thing's first and
all that.

-dr

Thorsten Wilms

2009-11-08 20:13:06 UTC

As a start, I'll have a try with collecting a list of hosts and plugins
and what features(/extensions) they provide or require right here on the
list ;)

Longterm it might be useful to have a way to query for this locally. For
an application that builds a matrix for the hosts and plugins you have
installed. Now, it's clear where to look for plugins, but some
convention/mechanism would be needed to fin the host RDF files, right?

--
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

David Robillard

2009-11-08 20:27:11 UTC

Post by Thorsten Wilms

As a start, I'll have a try with collecting a list of hosts and plugins
and what features(/extensions) they provide or require right here on the
list ;)
Longterm it might be useful to have a way to query for this locally. For
an application that builds a matrix for the hosts and plugins you have
installed. Now, it's clear where to look for plugins, but some
convention/mechanism would be needed to fin the host RDF files, right?

Ideally, yes, but it would be more productive to just put together this
data now and deal with that later.

Like everything else, it should probably be just bundles distributed,
installed, and discovered, in the usual way.

I will write a vocabulary and simple template later today.

-dr

Gabriel M. Beddingfield

2009-11-08 22:44:37 UTC

Post by David Robillard
pretty good idea. All that is needed as far as maintenance goes is for
hosts to supply a simple turtle document that says "I implement foo and
bar and baz extensions". The rest can be compiled into whatever fancy
human readable form you want, for every single plugin out there, by a

I would vote for XML for this, to better utilize all the parsers,
transformers, and presentation mechanisms already written and in place.
This isn't anti-turtle FUD, either. Turtle looks like it was a good
choice for the interface definitions.

Post by David Robillard
tool. If I provide a template, would anyone be willing to put together
these documents? I will gladly write the tool if the data is there, and
the problem will be solved, and a convention set that solves it in the
future with basically no effort involved.

I would.

-gabriel

Gabriel M. Beddingfield

2009-11-08 22:54:39 UTC

Post by Gabriel M. Beddingfield
I would vote for XML for this, to better utilize all the parsers,

Erm... nevermind. You've already finished it. :-)

-gabriel

David Robillard

2009-11-08 23:31:41 UTC

No. Everything LV2 is Turtle. Using a different format would just be
annoying and force the use of multiple technologies where one would do
and is guaranteed to already be used.

-dr

Patrick Shirkey

2009-11-08 22:48:51 UTC

I will work on the docs.

Patrick Shirkey
Boost Hardware Ltd

Chris Cannam

2009-11-08 20:23:09 UTC

Post by Nedko Arnaudov
1. Will the plugin X that I use a lot work on host Y that I want to try?
2. Will the host W that I use a lot work well with the plugin Z I've found?

Hm, I think you may have the wrong tense. I think the one basic
question that users will have is: Why doesn't this plugin work?

It's a LV2 plugin, this is an LV2 host. Why doesn't it appear in the
menu? Or, if it appears in the menu, why does it appear there but not
actually work at all? Or, why doesn't it look cool like it does in
the screenshots on the plugin's website, or like it does in
other-host-Y?

In other words, how can we convey the answers to questions like these
to users who haven't actually bothered to read any documentation
beforehand? (i.e. all users) And how do we do that without being
really annoying about it (e.g. having half the plugins in the menu pop
up an error dialog when you try to select them)?

Chris

David Robillard

2009-11-08 20:28:46 UTC

Post by Nedko Arnaudov
1. Will the plugin X that I use a lot work on host Y that I want to try?
2. Will the host W that I use a lot work well with the plugin Z I've found?

Hm, I think you may have the wrong tense. I think the one basic
question that users will have is: Why doesn't this plugin work?

This is a problem that hosts (can, and) should express to the user in
clear terms. They shouldn't have to go digging around on the internet
to figure this out (this is a large part of the reason I maintain these
"problems" are severely exaggerated around here).

Post by Chris Cannam
In other words, how can we convey the answers to questions like these
to users who haven't actually bothered to read any documentation
beforehand? (i.e. all users)

The number one rule of offline documentation is that nobody reads
offline documentation :)

-dr

Chris Cannam

2009-11-08 20:36:40 UTC

Hm, I think you may have the wrong tense. I think the one basic
question that users will have is: Why doesn't this plugin work?

This is a problem that hosts (can, and) should express to the user in
clear terms.

Yes, that's what I meant. I was fishing for ideas for how a host
might do this without being a complete pain in the arse for the user.

Chris

Paul Davis

2009-11-08 20:43:24 UTC

On Sun, Nov 8, 2009 at 3:36 PM, Chris Cannam

Hm, I think you may have the wrong tense. I think the one basic
question that users will have is: Why doesn't this plugin work?

This is a problem that hosts (can, and) should express to the user in
clear terms.

Yes, that's what I meant. I was fishing for ideas for how a host
might do this without being a complete pain in the arse for the user.

[X] This plugin was discovered but can't be used without hacking this
host and recompiling because its uses an extension that isn't
currently supported.

That kind of PITA? :)

Chris Cannam

2009-11-08 20:53:40 UTC

[X] This plugin was discovered but can't be used without hacking this
host and recompiling because its uses an extension that isn't
currently supported.
That kind of PITA? :)

That kind of PITA, for every new plugin that is installed, but perhaps
the bigger problem is what to do about optional extensions. The
plugin may run without them, but for all you know, it may run in a way
that is not really satisfactory for most real users of it. Warn them
at install time and they'll certainly have forgotten by the time the
plugin actually gets used, or at least will be unable to recognise the
symptom.

Chris

Chris Cannam

2009-11-08 20:59:52 UTC

On Sun, Nov 8, 2009 at 8:53 PM, Chris Cannam

[X] This plugin was discovered but can't be used without hacking this
host and recompiling because its uses an extension that isn't
currently supported.
That kind of PITA? :)

Also -- are you, like me, bored with LADSPA plugins crashing your host
in tedious, obvious ways? How about an LV2 plugin that expects a
particular extension but doesn't really need it so marks it as
optional, then turns out not to have been tested without it -- and,
wouldn't you know, every host except yours happens to support that
extension? Wouldn't you love to be the first host to run the untested
code path in production?

(I freely admit that this is a sort of FUD, but it happens to be a FUD
that is playing on my own mind at the moment. Reassure me.)

Chris

David Robillard

2009-11-08 21:26:08 UTC

Post by Chris Cannam
On Sun, Nov 8, 2009 at 8:53 PM, Chris Cannam

Post by Paul Davis
[X] This plugin was discovered but can't be used without hacking this
host and recompiling because its uses an extension that isn't
currently supported.
That kind of PITA? :)

Also -- are you, like me, bored with LADSPA plugins crashing your host
in tedious, obvious ways? How about an LV2 plugin that expects a
particular extension but doesn't really need it so marks it as
optional, then turns out not to have been tested without it -- and,
wouldn't you know, every host except yours happens to support that
extension? Wouldn't you love to be the first host to run the untested
code path in production?
(I freely admit that this is a sort of FUD, but it happens to be a FUD
that is playing on my own mind at the moment. Reassure me.)

Can't really do anything about plugins that crash(*), for whatever
reason. I don't think extensions increase this likelihood.

We just need tools to aggressively test plugins and find this stuff.

-dr

(* at least in realtime...)

h***@gmx.at

2009-11-08 21:06:12 UTC

On Sun, 8 Nov 2009 20:53:40 +0000

On Sun, Nov 8, 2009 at 8:43 PM, Paul Davis

[X] This plugin was discovered but can't be used without hacking
this host and recompiling because its uses an extension that isn't
currently supported.
That kind of PITA? :)

Example: Synth plugins in Ardour 2.x, loadable but unusable

David Robillard

2009-11-08 21:24:22 UTC

Post by Paul Davis
[X] This plugin was discovered but can't be used without hacking this
host and recompiling because its uses an extension that isn't
currently supported.
That kind of PITA? :)

There is no universal "install time" anyway.

Degree of neededness is a good point though. This could be added to
plugin data, but TBH for now I think required vs. not required is good
enough (e.g. there's bigger problems).

Maybe just one more level would be useful, so there's required, "you
really probably want this to use this plugin", and optional (bonus, if
you don't have it whatever).

-dr

Chris Cannam

2009-11-08 22:15:48 UTC

Post by David Robillard
There is no universal "install time" anyway.

Sorry, I meant that as shorthand for first run of the host after new
plugin was installed.

Chris

David Robillard

2009-11-08 22:34:54 UTC

Post by David Robillard
There is no universal "install time" anyway.

Sorry, I meant that as shorthand for first run of the host after new
plugin was installed.

I definitely think hosts should not be bugging users in any way at this
time.

-dr

David Robillard

2009-11-08 21:22:13 UTC

Post by Chris Cannam
Hm, I think you may have the wrong tense. I think the one basic
question that users will have is: Why doesn't this plugin work?

This is a problem that hosts (can, and) should express to the user in
clear terms.

Yes, that's what I meant. I was fishing for ideas for how a host
might do this without being a complete pain in the arse for the user.

Yeah, not displaying plugins at all is less than good.

It really depends on context, but something alone the lines of showing
all the plugins, but with unsupported ones grayed out with a little info
icon you can click for the reasoning why, would be best. A user option
could turn this off to make unsuitable plugins not be in the way and
shrink the list.

In menus it's a bit more complicated. I suppose clicking on an
unsupported plugin (that should be visually flagged in some way) can
bring up the 'why' info.

-dr

Patrick Shirkey

2009-11-08 22:45:20 UTC

Post by David Robillard
Yes, we need a
compatibility matrix or something along those lines. Everyone agrees.
There is really no need to continually state it.
SOMEONE MAKE ONE ON THE DAMNED WIKI THEN

I have offered my time for this project. I'm still waiting for the dust
to settle on the best way to present the data. A compatibility matrix is
not out of the question. However from my experience with alsa matrix it
is hard to keep it up to date. I would like to take things a step
further an automate that process if at all possible.

In regards to the issue with specifiying UI's I thin the best way around
the problem is to provide template code that people can work from. It
doesn't have to be the most flexible method that is known. It just has
to present a simple and elegant approach to the issue.

Having a template for every language and tool set that can be used to
build an ui that a busy but interested developer can quickly slot into
their own project with minimum tweaking will be a major step towards
opening up compatibility and getting more applications and ui's built.

Patrick Shirkey
Boost Hardware Ltd

Nedko Arnaudov

2009-11-08 12:00:17 UTC

Post by Gabriel M. Beddingfield
----------------
If you follow these guidelines, you may call yourself an "LV2 Synth Host"
and you will be able to work cleanly with every synth that calls itself an
"LV2 Synth Plugin."
+ Support (at least) extensions A, B, and C.

* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension

GTK hosts must support the GTK UI extension

Post by Gabriel M. Beddingfield
+ The synths will have several MIDI input ports (for note data)
and several audio output ports.
+ All configuration will be done with the events extension.
+ All feedback will be done with the events extension.

currently, parameter ports and monitor control (float) ports are
supposed to be used for this. event ports could be used for parameter
and monitor events but i'm not aware of someone using them for this
purpose.

Post by Gabriel M. Beddingfield
+ The plugins may provide a GUI interface. Its width will be
200, 400, 600, or 800 pixels. Its height will be a multiple
of 100 pixels.

I don't get why such restriction is needed.

Post by Gabriel M. Beddingfield
------------------
If you follow these guidelines, you may call yourself an "LV2 Synth
Plugin" and you will be able to work cleanly with every host that calls
itself an "LV2 Synth Host."
+ Freely use extensions A, B, and C. If you use any extra
LV2 extensions, try to make them optional. Otherwise,
please simply call yourself an "LV2 Plugin," because you
won't work with every LV2 Synth Host.

Plugin author can assume that these are available:
* the MIDI event extension
* the Event port extension
* the URI map extension

Plugin author can assume that one of these are available:
* the external UI extension (toolkit agnostic, always a window)
* the GTK UI extension (gtk specific, may be embeded)

Post by Gabriel M. Beddingfield
+ Provide several MIDI in-ports for note data, and several
audio out-ports.
+ All configuration will be done with the events extension.
(This does not prohibit you from also doing the same over MIDI)
+ All feedback will be done with the events extension.
+ You are encouraged to create a GUI for your plugin. Its
width shall be 200, 400, 600, or 800 pixels. Its height
shall be a multiple of 100 pixels.

See comments for matching guidines for hosts above.

UI extensions are of course optional but hosts will handle this
gracefully anyway, as defined by LV2 itself. I.e. if plugin provides no
GUI, then host will probably use generic one (prefered) or will not
allow parameter tweak. If host does not support these GUI extensions, it
will not show the GUIs. That said, most users expect plugins to have
GUIs, and GUIs running on same host as the DSP code.

Some words about the GUI extension problems. If we want (we do, right?)
wider adoption of LV2, GUIs must be toolkit agnostic and at least C++
SDK must be provided. External UI may not be perfect but IMO (obviously)
it is the best we have in this direction. The GTK extension could be
supported automagically if plugin author inherits its GUI class from the
GTK plugin GUI base class.

proposed class hierarchy:

lv2_plugin_base
/ \
/ \
/ \
/ \
lv2_synth_plugin lv2_effect_plugin
| |
mysynth myeffect

lv2_plugin_base implements the base lv2 plugin functionality
lv2_synth_plugin implements the lv2 synth functionality
lv2_effect_plugin implements the lv2 effect functionality

lv2_ui_base
/ \
/ \
/ \
lv2_gtk_ui_base lv2_external_ui_base
\ / | \
\ / | \
\ / | \
\ / | \
\ / | \
lv2_gtk2_gui lv2_qt4_gui lv2_fltk2_gui
| | |
mygtkui myqtui mygltkui

lv2_ui_base implements the base UI extension
lv2_gtk_ui_base implements the GTK variant of the UI extension
lv2_external_ui_base implements the external variant of the UI extension
lv2_gtk2_gui implements the base functionality of a GTK GUI
lv2_qt4_gui implements the base functionality of a QT4 GUI
lv2_fltk2_gui implements the base functionality of a FLTK2 GUI

Current problems with the UI extension (both gtk and external variants):
* there is no easy way for UI to know the sample rate
* it is incompatible with lv2core revision 3

If new UI extension is designed, it should probably use event
ports. When the original UI extension was designed, event port extension
was not avialable.

Of course, others are free to disagree.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Gabriel M. Beddingfield

2009-11-08 12:35:51 UTC

Post by Gabriel M. Beddingfield
+ The plugins may provide a GUI interface. Its width will be
200, 400, 600, or 800 pixels. Its height will be a multiple
of 100 pixels.

I don't get why such restriction is needed.

So that the host application can lay out the plugin widgets cleanly.[1]

+---------+----------+----------+----------+
| Foomatic Synth | Reverb | O-Drive |
| () () ---|---- | --|---- | () () |
| () () [1:Buzz ] | () () | () () |
+--------------------+----------+----------+
| LinuxSampler () () () () () () () () () |
| [16: Piano ] ------|-- () () () () |
| --|------ () () () |
+------------------------------------------+

After reading your comments, I suppose I was thinking of "internal" GUI's
where the widgets are layed out by the host application. For example, if
I was writing an application, I couldn't use zynadd's UI because it's way
to large (both the overall size and the size of the widgets).

I (personally) really don't like having plugin windows flying all over the
place. I think they should be layed out in the host application. (And I
also think they should be widget-toolkit agnostic --
Qt/GTK/FLTK/whatever.)

Thanks,
Gabriel

p.s. I'm still digesting the rest of your post.

[1] After more thought, it would probably be best to drop the 600 width.

Paul Davis

2009-11-08 12:40:19 UTC

On Sun, Nov 8, 2009 at 7:35 AM, Gabriel M. Beddingfield

Post by Gabriel M. Beddingfield
I (personally) really don't like having plugin windows flying all over the
place. I think they should be layed out in the host application. (And I
also think they should be widget-toolkit agnostic --
Qt/GTK/FLTK/whatever.)

when you come up with a way to do that, please do let us know. this
has been on the table for at least 8 years and no acceptable solutions
have ever emerged. they either offer too little control to the plugin
developer, or simply cannot integrate with the event loop of the host.

Gabriel M. Beddingfield

2009-11-08 12:46:04 UTC

Post by Paul Davis

Thanks! I didn't realize this was the quest for the Holy Grail of plugin
GUI. :-)

-gabriel

Gabriel M. Beddingfield

2009-11-08 14:30:28 UTC

Post by Paul Davis
when you come up with a way to do that, please do let us know. this
has been on the table for at least 8 years and no acceptable solutions
have ever emerged. they either offer too little control to the plugin
developer, or simply cannot integrate with the event loop of the host.

OK, I've dutifully searched the LAD and LV2 archives..... :-)

Why did XEmbed not pan out? I didn't see anything negative regarding its
adoption... people just quit talking about. It doesn't even look like it
was discussed on LV2-dev.

-gabriel

Paul Davis

2009-11-08 14:54:07 UTC

On Sun, Nov 8, 2009 at 9:30 AM, Gabriel M. Beddingfield

OK, I've dutifully searched the LAD and LV2 archives..... :-)
Why did XEmbed not pan out? I didn't see anything negative regarding its
adoption... people just quit talking about. It doesn't even look like it
was discussed on LV2-dev.

(a) it doesn't work very well
(b) it requires functioning support from whatever toolkit the host is written in
(c) it doesn't solve the whole issue
(d) check how well it (hasn't) worked out for mozilla/firefox (where
it is used with varying levels of success)
(e) LV2 has no connection to X Window, and it would be nice to have a
solution that wasn't tied into a little-used X11 extension

David Robillard

2009-11-08 16:11:09 UTC

OK, I've dutifully searched the LAD and LV2 archives..... :-)
Why did XEmbed not pan out? I didn't see anything negative regarding its
adoption... people just quit talking about. It doesn't even look like it
was discussed on LV2-dev.

I don't think anyone who cares about Qt has done much in LV2 land yet :)

-dr

David Robillard

2009-11-08 16:09:34 UTC

Post by Paul Davis
On Sun, Nov 8, 2009 at 7:35 AM, Gabriel M. Beddingfield

Qt can now use the glib main loop. It seems like this should be
feasible these days, though I don't know if anyone has done it.

(In any case it doesn't affect the extension itself)

-dr

Chris Cannam

2009-11-08 17:46:11 UTC

Post by David Robillard
Qt can now use the glib main loop.

Not just "can", it does by default since Qt 4.4. I think the
intention was exactly to allow cross-toolkit plugins. So it's quite
likely there is a way to make this work, though obviously not with the
existing GTK UI extension. Wish I had time to look into this myself,
but I haven't.

Chris

David Robillard

2009-11-08 18:59:41 UTC

Post by David Robillard
Qt can now use the glib main loop.

Not just "can", it does by default since Qt 4.4. I think the
intention was exactly to allow cross-toolkit plugins. So it's quite
likely there is a way to make this work

Yay

Post by Chris Cannam
, though obviously not with the
existing GTK UI extension.

Why not?

-dr

Chris Cannam

2009-11-08 19:10:06 UTC

Post by Chris Cannam
likely there is a way to make this work

Yay

Post by Chris Cannam
, though obviously not with the
existing GTK UI extension.

Why not?

Because it passes a GTK window, doesn't it? (Doesn't it?) Which has
no meaning anywhere except GTK.

Chris

Nedko Arnaudov

2009-11-08 19:18:04 UTC

Post by Chris Cannam
likely there is a way to make this work

Yay

Post by Chris Cannam
, though obviously not with the
existing GTK UI extension.

Why not?

Because it passes a GTK window, doesn't it? (Doesn't it?) Which has
no meaning anywhere except GTK.

It passes GTK *widget*.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Chris Cannam

2009-11-08 19:19:02 UTC

Because it passes a GTK window, doesn't it? (Doesn't it?) Which has
no meaning anywhere except GTK.

It passes GTK *widget*.

Right, OK, same thing though from this point of view. GTK anything.

Chris

David Robillard

2009-11-08 19:25:30 UTC

Post by Chris Cannam
Because it passes a GTK window, doesn't it? (Doesn't it?) Which has
no meaning anywhere except GTK.

It passes GTK *widget*.

Right, OK, same thing though from this point of view. GTK anything.

How can one possible embed a Gtk widget without... having a Gtk
widget? :)

Again, to be sure this is clear, there is no "Gtk UI extension". The UI
extension can return a UI of any type (as a void pointer), Gtk just
happens to be one of them. Qt or Fltk could be another, or some kind of
higher level wrapper thingamawhatsit that would be necessary to support
this - anything at all.

-dr

Chris Cannam

2009-11-08 19:43:38 UTC

Because it passes a GTK window, doesn't it? (Doesn't it?) Which has
no meaning anywhere except GTK.

It passes GTK *widget*.

Right, OK, same thing though from this point of view. GTK anything.

How can one possible embed a Gtk widget without... having a Gtk
widget? :)

Uh, with an X window or whatever. GTK and Qt are both X toolkits
after all. In any case, it doesn't have to be embeddable to be useful
-- it only has to be in-process (even if in a separate window) to be
better than the DSSI alternative.

Post by David Robillard
Again, to be sure this is clear, there is no "Gtk UI extension". The UI
extension can return a UI of any type (as a void pointer), Gtk just
happens to be one of them.

But it's only of any use at all if the host and plugin know what the
void pointer points to. Presumably the extension provides a way to
communicate that; otherwise, it either really is a GTK UI extension
(because there are GTK plugins that use it already, so all hosts must
assume the unknown void pointer is a GTK widget pointer), or else it's
just a very fancy segmentation fault extension.

Anyway, even if you can write plugins using any toolkit and run them
in a host that uses any toolkit, I posit that a UI extension in which
the UIs only appear if the plugin and host happen to be using the same
toolkit is not a very useful one.

Chris

Chris Cannam

2009-11-08 20:11:37 UTC

On Sun, Nov 8, 2009 at 7:43 PM, Chris Cannam

Uh, with an X window or whatever. [...]

Post by David Robillard
Again, to be sure this is clear, there is no "Gtk UI extension". The UI
extension can return a UI of any type (as a void pointer), Gtk just
happens to be one of them.

... but of course you're right that if it allows any pointer to be
passed (provided it's possible to say what it is), then the same
extension should be usable for passing "the X window" or whatever it
is you have. Though that still complicates the social problem of how
to know what extensions are needed or supported, if some extensions
only work some of the time.

Chris

David Robillard

2009-11-08 20:20:10 UTC

Post by Chris Cannam
Because it passes a GTK window, doesn't it? (Doesn't it?) Which has
no meaning anywhere except GTK.

It passes GTK *widget*.

Right, OK, same thing though from this point of view. GTK anything.

How can one possible embed a Gtk widget without... having a Gtk
widget? :)

Then it's X specific. I'd rather implement the embeddey part in a
library that can take a void* pointer to a somethingorother (where the
type is specified) and deal with the details.

Having a bunch of X specific junk in hosts isn't that much more
palatable than a bunch of Gtk/Qt/whatever specific junk anyway.

Post by David Robillard
Again, to be sure this is clear, there is no "Gtk UI extension". The UI
extension can return a UI of any type (as a void pointer), Gtk just
happens to be one of them.

Obviously there is ;)

Post by Chris Cannam
Anyway, even if you can write plugins using any toolkit and run them
in a host that uses any toolkit, I posit that a UI extension in which
the UIs only appear if the plugin and host happen to be using the same
toolkit is not a very useful one.

It is an extension by which you can easily find a UI of some type for a
plugin. No more, no less. What is possible with those types, or what
types are used in practice, is (deliberately) an orthogonal problem.

-dr

David Robillard

2009-11-08 16:08:04 UTC

Post by Gabriel M. Beddingfield
+ The plugins may provide a GUI interface. Its width will be
200, 400, 600, or 800 pixels. Its height will be a multiple
of 100 pixels.

I don't get why such restriction is needed.

This is a good motivation, but pixel widths are the devil and should be
avoided whenever possible.

On a related note, plugin UIs should be heavily encouraged to be as
SMALL as possible. Some UIs are obscenely large, and all the wasted
space seriously sucks for environments that embed them.

++

-dr

Gabriel M. Beddingfield

2009-11-08 17:58:01 UTC

Post by David Robillard
This is a good motivation, but pixel widths are the devil and should be
avoided whenever possible.

I agree. Can you suggest another metric?

-gabriel

David Robillard

2009-11-08 19:01:40 UTC

Post by David Robillard
This is a good motivation, but pixel widths are the devil and should be
avoided whenever possible.

I agree. Can you suggest another metric?

Decent UIs are sized based on text size, which is variable. I don't
think it's really possible to do this.

A better solution for a host that wants nice alignment like this would
be to simply round up the size to the nearest multiple of whatever.

-dr

David Robillard

2009-11-08 16:06:25 UTC

Post by Gabriel M. Beddingfield
+ Support (at least) extensions A, B, and C.

* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension
GTK hosts must support the GTK UI extension

To clarify, since this could be misleading: the UI extension is not a
Gtk UI extension, it can work with any toolkit or other form of UI,
including 'external' ones.

Post by Nedko Arnaudov
* there is no easy way for UI to know the sample rate
* it is incompatible with lv2core revision 3

These can both be fixed without breaking backwards compatibility by
passing features to the UI.

I said the last time something came up with the UI init function that
things should just be passed as features instead of breaking the thing
every time we feel like adding a parameter for "convenience". That time
has certainly come now.

Post by Nedko Arnaudov
If new UI extension is designed, it should probably use event
ports.

It should be completely port type agnostic, as it is now.

-dr

Gabriel M. Beddingfield

2009-11-08 18:44:16 UTC

Thanks Nedko....

Post by Gabriel M. Beddingfield
+ Support (at least) extensions A, B, and C.

* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension

What about the dynparam extension? That seems appropriate to require from
a synth host.

Post by Nedko Arnaudov
GTK hosts must support the GTK UI extension

[snip]

FWIW, we're getting over my head now. I'm going to go do LV2 code in my
sandbox for a while to catch up. :-)

-gabriel

David Robillard

2009-11-08 19:08:31 UTC

Post by Gabriel M. Beddingfield
Thanks Nedko....

Post by Gabriel M. Beddingfield
+ Support (at least) extensions A, B, and C.

* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension

What about the dynparam extension? That seems appropriate to require from
a synth host.

This extension is IMO a kludge (because it's not extensible and is too
kitchen sinkey), which is why I havn't implemented it (and won't). It
doesn't mesh well with anything else.

A more generic dynamic ports extension (that allows dynamic
adding/removing of ports without all the other crap) would certainly be
nice though.

-dr

Nedko Arnaudov

2009-11-08 19:17:18 UTC

Post by Gabriel M. Beddingfield
Thanks Nedko....

Post by Gabriel M. Beddingfield
+ Support (at least) extensions A, B, and C.

* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension

What about the dynparam extension? That seems appropriate to require from
a synth host.

It seems to be quite unpopular. As for Ingen+zynadd, the biggest problem
is how Ingen will handle 100+ parameter ports. If they are all
"automatable", of course.

--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>

David Robillard

2009-11-08 19:22:36 UTC

Post by Gabriel M. Beddingfield
Thanks Nedko....

Post by Gabriel M. Beddingfield
+ Support (at least) extensions A, B, and C.

* the MIDI event extension
* the Event port extension
* the URI map extension
* the external UI extension

What about the dynparam extension? That seems appropriate to require from
a synth host.

It seems to be quite unpopular. As for Ingen+zynadd, the biggest problem
is how Ingen will handle 100+ parameter ports. If they are all
"automatable", of course.

If you mean visually, I think a straightforward "view priority" or
something along those lines property is the solution to this (this
problem is common to basically anything that shows all controls, not
just ingen).

Priority 0 would be a small number of high level controls that should be
visible whenever any control are (e.g. overall gain), Priority 1 would
be slightly more low level controls (e.g. filter cutoff), and so on.
Priorities could be associated with groups as well as ports to make
things more managaeable.

Easy enough, just needs doing.

-dr

David Robillard

2009-11-08 15:58:51 UTC

Post by Patrick Shirkey
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?

I don't think so. ATM, there's plenty of high-quality reference code...
especially with Lars's tutorial. This is a different issue.

Post by Patrick Shirkey
It's clear that we need to better define the plugin publishing and
dependency system for LV2?

Not quite (though that would be a Good Thing).
More like a standard that says something like......
----------------
If you follow these guidelines, you may call yourself an "LV2 Synth Host"
and you will be able to work cleanly with every synth that calls itself an
"LV2 Synth Plugin."
+ Support (at least) extensions A, B, and C.
+ The synths will have several MIDI input ports (for note data)
and several audio output ports.

Several? Why?

Post by Gabriel M. Beddingfield
+ All configuration will be done with the events extension.

Nothing more powerful than MIDI even exists for this yet. Nothing to do
with synths.

Post by Gabriel M. Beddingfield
+ All feedback will be done with the events extension.

See above. Also nothing to do with synths.

Post by Gabriel M. Beddingfield
+ The plugins may provide a GUI interface. Its width will be
200, 400, 600, or 800 pixels. Its height will be a multiple
of 100 pixels.

Ridiculous restriction. Also nothing to do with synths.

Extensions that are not necessary to function at all should be optional
anyway, in all cases.

Post by Gabriel M. Beddingfield
Would somthing like this be *so* bad?

What benefit does it have? What problem does it solve? How is it even
any different from what might be the equivalent for an "effect" plugin?

Simple guidelines for how to make a plugin likely to work in widespread
places is good, but it doesn't make any sense to try and define "LV2
Synth" things like this. There is zero technological difference between
most synths and most effects, other than the presence of an event port
that supports MIDI being more likely.

If you want to start such a thing, it's a wiki for a reason ;) It's
much easier to revise there than on the list.

-dr

Gabriel M. Beddingfield

2009-11-08 17:49:59 UTC

Post by Gabriel M. Beddingfield
+ The synths will have several MIDI input ports (for note data)
and several audio output ports.

Several? Why?

Several as in "a non-negative integer." I.e. the host should be prepared
for a synth that has 1, 2, 3, 4, or even 0 ports.

Post by Gabriel M. Beddingfield
+ All configuration will be done with the events extension.

Nothing more powerful than MIDI even exists for this yet. Nothing to do
with synths.

:-( Good to know, though.

Post by Gabriel M. Beddingfield
+ Freely use extensions A, B, and C. If you use any extra
LV2 extensions, try to make them optional. Otherwise,
please simply call yourself an "LV2 Plugin," because you
won't work with every LV2 Synth Host.

Extensions that are not necessary to function at all should be optional
anyway, in all cases.

But if you know up-front which things to make optional... you can adjust
your implementation.

Post by Gabriel M. Beddingfield
Would somthing like this be *so* bad?

What benefit does it have? What problem does it solve? How is it even

So that I can write a synth plugin and be reasonably assured it will work
with "everyone's" LV2 synth host. So that I can write an LV2 host and be
reasonable assured that it work with "everyone's" LV2 synth plugin.

Post by David Robillard
any different from what might be the equivalent for an "effect" plugin?

Because Synths are usually more complicated than an effect, and less
well-defined conceptually. There's presets, samples, MIDI
implementations, sound libraries, routings, effects in the sampler,
variable number of ports, various ways to pass data, etc.

Post by David Robillard
If you want to start such a thing, it's a wiki for a reason ;) It's
much easier to revise there than on the list.

...but much harder to *discuss*. ;)

-gabriel

Gabriel M. Beddingfield

2009-11-09 01:43:46 UTC

Post by David Robillard
If you want to start such a thing, it's a wiki for a reason ;) It's
much easier to revise there than on the list.

So how does one get an account for the wiki?[1] I clicked the "log in /
create account" link[2] -- but there was no option to create an account.

Thanks,
Gabriel

[1] http://lv2plug.in/docs/index.php?title=Main_Page
[2]
http://lv2plug.in/docs/index.php?title=Special:Userlogin&returnto=Main_Page

David Robillard

2009-11-09 02:07:28 UTC

Post by David Robillard
If you want to start such a thing, it's a wiki for a reason ;) It's
much easier to revise there than on the list.

So how does one get an account for the wiki?[1] I clicked the "log in /
create account" link[2] -- but there was no option to create an account.

Hrm, WTF! Good question.

Steve?

-dr

David Robillard

2009-11-08 15:50:58 UTC

Post by Patrick Shirkey
Would a set of reference template code written for the various languages
that we have at our disposal be of any use here?

Small examples would be great.

Post by Patrick Shirkey
We need a more transparent way of referencing an extension/plugin by to
it's dependencies.

This is why resolvable URIs are nice. Ideally, the URI is resolvable
and takes you to nice human readable documentation as well as the
implementation/header/etc parts of the extension. This way whenever you
encounter an extension URI you just stick it in your browser and all the
info is right there

e.g. http://lv2plug.in/ns/dev/preset would take you to
http://lv2plug.in/ns/dev/presets.lv2/presets.html

(I don't have the URIs mapping correctly yet)

-dr

David Robillard

2009-11-08 15:44:03 UTC

Post by Gabriel M. Beddingfield
Looking at this, people say, "This is good, but it's kind of a mess at the
moment. Can we get some sort of 'canonical list of extensions' or
/something/ stable for devs to work from?" To which Dave replies, "FUD!
FUD! FUD! Such a list accomplishes nothing!"

Actually I specifically said making a list of "well supported"
extensions was a good idea.

Making a bunch of different "categories" of LV2 support is stupid, and
claiming the extension thing is some apocalyptic disaster with no
evidence is FUD.

Post by Gabriel M. Beddingfield
Dave *seems* to think that "The
Problem" isn't a problem.

Dave is, at this moment, working on "The Problem" (documentation).
Actions speak louder than words.

-dr

f***@kokkinizita.net

2009-11-07 22:09:40 UTC

Post by David Robillard
This wouldn't be an LV2 plugin at all.

In spirit, no. But technically it would be a
perfectly conforming plugin.

Ciao,

--
FA

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

David Robillard

2009-11-08 15:45:50 UTC

Post by David Robillard
This wouldn't be an LV2 plugin at all.

In spirit, no. But technically it would be a
perfectly conforming plugin.

Huh? An LV2 plugin in the code sense is a shared library with a
lv2_descriptor function that returns a struct LV2_Descriptor (just like
LADSPA).

I don't see how a shared library with some random C++ object in it is an
LV2 plugin... or what the point would be anyway

-dr

f***@kokkinizita.net

2009-11-08 18:13:28 UTC

Post by David Robillard
This wouldn't be an LV2 plugin at all.

In spirit, no. But technically it would be a
perfectly conforming plugin.

Huh? An LV2 plugin in the code sense is a shared library with a
lv2_descriptor function that returns a struct LV2_Descriptor (just like
LADSPA).

Yes. Please rewind a few messages and read again.
The idea was an extension that requires the host
to obtain a pointer to a C++ object from the plugin.
This C++ object (derived from some base class which
is part of the extension definition) then provides
all other information (ports, process method, etc.).
This would bypass all LV2 methods, but still be an
LV2 plugin.

Ciao,

--
FA

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

David Robillard

2009-11-08 19:06:04 UTC

Post by David Robillard
This wouldn't be an LV2 plugin at all.

In spirit, no. But technically it would be a
perfectly conforming plugin.

Huh? An LV2 plugin in the code sense is a shared library with a
lv2_descriptor function that returns a struct LV2_Descriptor (just like
LADSPA).

I assumed this object would be an auxiliary thing, because that's all
that makes sense.

Making an LV2 plugin that doesn't actually use the LV2 methods doesn't
make any sense. It could technically have those fields but have them
not do anything and theoretically be a "valid" LV2 plugin I suppose, but
it's a completely braindead and pointless thing to do anyway, so who
cares...

If the motivation for this is the fact that this class already exists,
then simply make the LV2 methods call the methods on that object. The
"bypass LV2 entirely" thing you describe is crazy. No point in using
LV2 at all, that way. At best it's just being a huge pain in the host
author's ass for no reason.

-dr

David Robillard

2009-11-05 23:33:42 UTC

Post by f***@kokkinizita.net
"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

Steve Harris

2009-11-06 12:57:03 UTC

For anyone genuinely interested and not just taking vain pot shots to
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

Jörn Nettingsmeier

2009-11-07 12:41:43 UTC

Post by Steve Harris

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.

can you elaborate on this?

archive links would be good, too.

David Robillard

2009-11-07 17:59:42 UTC

Post by JÃ¶rn Nettingsmeier

Post by Steve Harris

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.

can you elaborate on this?

Labels are not useful as an identifier for LADSPA ports at all - there
are plugins out there that use the same label for several ports, for
example. Despite this there's code out there that attempts to use them
as such.

More generally there's been a lot of confusion and screw-up over
identification of plugins. The spec says to use the ID, which is
annoyingly centralized and limited. There are plugins in the wild with
conflicting IDs. Many people suggested using the library name and
plugin label as an identifier instead. Unfortunately this doesn't work,
there are packages of the same plugins with different library names, or
different distributions of plugins among libraries. I don't believe
there is a single correct way to refer to a LADSPA plugin that actually
works with all the plugins out there. Many people just have an
extremely small number of plugins (e.g. 2 or 3 of the most popular big
packages) and don't notice.

The index vs. symbol thing with LV2 is more to do with dynamicism and
versioning, though.

-dr

Chris Cannam

2009-11-07 20:15:49 UTC

Post by JÃ¶rn Nettingsmeier

Post by Steve Harris
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.

can you elaborate on this?
archive links would be good, too.

I think Steve may be thinking of the inflammatory subject of how you
identify plugins, not ports. I'm pretty sure LADSPA ports are always
by number.

Chris

Steve Harris

2009-11-08 20:04:43 UTC

Post by JÃ¶rn Nettingsmeier

Post by Steve Harris
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.

can you elaborate on this?
archive links would be good, too.

I think Steve may be thinking of the inflammatory subject of how you
identify plugins, not ports. I'm pretty sure LADSPA ports are always
by number.

Oh you're right, brain fart on my part.

Still the port ID in LV2 was a hangover from LADSPA, which was my main
point.

- Steve

David Robillard

2009-11-05 15:54:24 UTC

Post by Gordon JC Pearce

Post by 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

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

Jörn Nettingsmeier

2009-11-05 09:17:09 UTC

Post by Ulrich Lorenz SchlÃ¼ter
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!

Adrian Knoth

2009-11-05 09:20:42 UTC

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

Hi!

Post by JÃ¶rn Nettingsmeier
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: ***@thur.de 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

David Robillard

2009-11-05 15:55:32 UTC

Post by Ulrich Lorenz SchlÃ¼ter
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

Jeff McClintock

2009-11-08 06:41:20 UTC

-dr

GMPI is quietly and successfully in use as the new native plugin format of
SynthEdit. I've so far written 70 plugins with it, and others are writing
more. SynthEdit's previous plugin format has about 1000 plugins available,
hopefully also will be ported to GMPI (aka SEM V3)... so GMPI can't really
be called vaporware any more.

Jeff

Chris Cannam

2009-11-08 11:28:52 UTC

Post by Jeff McClintock
GMPI is quietly and successfully in use as the new native plugin format of
SynthEdit.

Interesting. Can you link to an API reference or the like?

Chris

Emanuel Rumpf

2009-11-08 12:50:14 UTC

Post by David Robillard
<insert obligatory GMPI joke here>

-dr

Paul Davis

2009-11-08 12:55:09 UTC

FLOSS poeple - let's rather ignore GMPI as long as we can.

I don't recall you being involved in the GMPI process. I was, and so
was Jeff (and others include Steve Harris).

The final outcome of the organized attempt to define and implement
GMPI was not terribly satisfactory, but that was partly because the
people who put the most time into the process (including Jeff) were
unhappy about MMA's attempt to control the rest of the process.

Imagining that GMPI was some kind of corporate shill attempt at a
plugin standard is completely wrong. It was designed by FLOSS-friendly
developers, with the intent on their part that it would remain that
way. The fact that the MMA wasn't willing to play ball with that idea
was what helped kill it - we had actually reached a final
specification. the MMA does not own that spec.

Jeff has continued to refine it via experience .. that doesn't
necessarily mean that its a viable plugin API at this point, but you
could at least be a bit more informed about its history before
denouncing as non-FLOSS-ish ...

Emanuel Rumpf

2009-11-08 13:23:06 UTC