[LAD] [ANN] LV2 beta3

Thomas Vecchione seablaede at gmail.com
Wed May 9 17:28:31 UTC 2007

Gonna answer several posts with this I think in the interest of 
simplicity as I tihnk I was misunderstood somewhat....


> You could have meta-extensions that were simply a collection of other
> extensions. "To support this extension, a host must support extensions
> A, B, and C". Or something like that.

Definitely a possibility, that is exactly what I was referring to with 
'Profiles'.  For example an Audio-Instrument profile might support XYZ 
while a Video Profile might support others, as if I recall correctly 
part of the point of LV2 was to support not just audio but possibly 
other things as well?  A GUI profile might be another one(Not saying it 
is a good idea, just providing possible examples)?

Whatever the case of how that is handled, simplicity for the user as 
well as the programmer needs to be considered.  Even the profiles 
mentioned above would add complexity in for the end user though.

> I don't think there is any huge danger of that happening. People will
> probably mostly use a few popular hosts, plugin writers will make sure
> that their plugins work in those hosts (if feasible) and host writers
> will try to support as many plugins as possible. I guess it depends on
> how creative (or how disciplined) LV2 programmers are.

I think that is being either very optimistic or pessimistic, or both at 
the same time(If that is possible).  Writing plugins for a few specific 
hosts is a good idea, of course then you are limiting the capabilities 
of others also developed with LV2 as they might not be able to support 
all extensions out of the box quickly enough to become popular.  As much 
as I love Ardour, I would hate for it to be the only option out there, 
then we are back to Pro-Tools all over again.

Also depending on LV2 programmers to always be completely disciplined is 
being kinda optomistic IMO.  Nothing against any current programmers, 
but if we want to encourage people to develop plugins, some of those 
people may just be getting started in programming.  Some guidelines are 
not a bad thing in that regard, and may even encourage folks to stay 
logical and disciplined.

> There is a good argument against having a large core specification; the
> larger it is, the harder it is to write hosts, and the fewer hosts will
> be written.

I am not arguing that at all actually.  I think Firefox's greatest 
strength early on that it is starting to lose was the fact they aimed 
for very lightweight and allowed extensions.  However now they are 
building more into the browser and less via extensions, instead of 
shipping it with those functionalities as extensions that can be 
disabled if desired.


> Hosts will be able to not ever list plugins they can't use, afaik.

Unfortunatly that has nothing to do with my concern though.  The problem 
isn't that hosts won't list the plugin, it is that a plguin that works 
here in program X, and I like the plugin but maybe not the program, 
doesn't work here because a host y has not done that particular extension.

It could be looked at as the job of the programmer to support the 
extension, but then you are adding complexity into the programmer's 
lives as well by making them follow every custom extension to support 
all these great plugins.

> In the worst case we will need a table of what works where  :) 

Yes but that should be ABSOLUTE worst case.  I have enough problems 
explaining audio on linux half the time to others, that if I was to be 
asked every five minutes, well I have a plugin that works in RoseGarden 
but wont work in Muse, but they both support LV2, trying to explain the 
concept of extensions individually I think would be a problem.

Again I come back to profiles only because I couldn't think of a better 
solution at the time(So people start suggesting;), but if I have to 
point newcomers to a chart every time they want to knokw if their plugin 
works, and maybe it hasn't been tested... Might as well be back to 
VST/fst on linux debates there.


> I expect the majority of plugins will only use the core spec. The hosts can tell which plugins they don't have support for, and why so they could do something intelligent in the UI (greying out and tooltips or whatever). 

I completely agree, but things like this I think need to be addressed in 
a way that is simple for non-programmers to understand from the get-go.

> There's also a lot of support to allow plugins to gracefully degrade, or provide alternative implementations when a feature that they'd like is not present.

And I think that is also a good idea.

> Sure, why not? It's just a social contract. 

The catch is keeping it as simple as possible so we don't have an audio1 
audio2 and audio 3.4 profile all at once IMO.

> They wont have to. The point that they might not understand why for eg. Ardour can't load one of Nedko's plugins is reasonable though. 

And the latter portion was of course my primary point/concern.

> That's a possibility for the future, I would expect any LV2 1.1 to be the core spec + a set  of commonly used extensions. 

And while my opinion only matters a limited extent, I would suggest that 
things like that get addressed earlier rather than later myself.

> Discussing spec issues in an open forum like this though is a futile effort, and it's simply not true that you can't get a lot done with the core spec. LV2 is more capable than LADSPA, and there are some hundred LADSPA plugins, which work to some degree :)

I didn't mean to suggest the core spec was not capable.  I am just 
trying to avoid where I see confusion possibly arriving in the future.


> As I pointed out, a lot of thought has been put into this.  The
> information is always there to know if, and why, a plugin is or is not
> usable.  So graceful failure from an end user perspective (or,
> preferably, just hiding the plugin entirely and avoiding confusion and
> clitter) is possible.

And your average non-programmer end-user will understand the plugin is 
LV2, and wonder why the heck it is not working in this program.

> Think of it as extra plugins that would not exist /at all/ if the spec
> wasn't extensible in this way.  Nothing lost, right?

And lots of complexity gained.  That complexity is Linux's strength, but 
also its weakness as it rarely gets addressed in a way that provides the 
simplicity needed for an average user.  I am not saying everything 
should be addressed in such a way, but I am saying something like this 
that is aimed to be used by the average end-user musician/producer/sound 
designer/etc should be.

Once again my intent is not to belittle the extensivenesses of it.  In 
fact I might almost prefer LV2 be the base framework for ports that can 
carry ANY sort of data for example, and then have the profiles define 
what that data is, instead of anything being built into it, and ship 1.0 
with a basic profile or three that people can implement based off what 
their program is.

I admit I should have suggested that much earlier in the process, if I 
actually expected it to be thought about, I had only lightly been 
following it, sorry.  But just to give an idea of where I stand that 
hopefully will clarify my position of it.  I am not saying that the 
extensibility is a bad thing, I am saying that in the end the plugin 
format needs to be given to the end user in a way that will seem 
extremely simple to them.


More information about the Linux-audio-dev mailing list