Gonna answer several posts with this I think in the interest of
simplicity as I tihnk I was misunderstood somewhat....
Lars:
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.
Thorsten:
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.
Steve:
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.
Dave:
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.
Seablade