[LAD] [ANN] LV2 beta3
drobilla at connect.carleton.ca
Wed May 9 20:18:07 UTC 2007
On Wed, 2007-05-09 at 13:28 -0400, Thomas Vecchione wrote:
> 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 really see the point of these "profiles" at all, to be honest.
Seems like just defining things for the sake of defining things.
> 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.
The perspective of this argument is getting a bit hand wavey. It's
really quite simple: there are "extra" features you can use/create/etc.
Either a plugin author supports these features, or not.
Either a host author supports these features, or not.
Either way, everything just works (or not) as it should.
I understand the idea of "plugin A doesn't work in host B" is maybe
unnerving at first glance, but you're looking at it from a strange
perspective and trying to come up with solutions to a problem that
simply doesn't exist.
To pick an obvious example, consider GUIs:
Host H is a command line app, and doesn't support GUIs.
Plugin P is a plugin with an optional GUI.
Plugin G is a plugin with a mandatory GUI (silly example, yes).
P works in H, P's GUI doesn't.
G doesn't work in H.
Of course GUIs don't work in H - it doesn't support GUIs! There is no
More information about the Linux-audio-dev