[LAD] [ANN] LV2 beta3

[Thomas Vecchione]

> the problem will be rather: why has this plugin a GUI in ardour and
> ingen and not in qtractor.
> 
> while this other plugin has a gui in qtractor and non in ardour and
> ingen. 
> 

That is an exact example of one case that is certainly possible.

> What has understanding internals to do with this?
> All that will need to be understood is that is-an-LV2 is not 
> enough to describe a plugin or host.

And how is it doing to be described is my point.  At the moment it is 
being described as a function of what internal extensions are there in 
the case of something that does beyond the spec.  If this was one or two 
extensions it wouldn't be bad at all, but since we are aiming for 
expandability BEYOND what we can thing of right now I think it is a 
large mistake to not plan for what would happen if there are 50 
different extensions.

> Do you propose to not have a plugin standard that can be extended for 
> various current and possible future needs to avoid some possible user 
> confusion?

Absolutely not, and nowhere did I say that.

What I am attempting to propose is a good, end-user-friendly, be found 
other than just describing individual extensions that gives end-users a 
strong idea of what will and will not work.  That is it.

> Shall all hosts be forced to support all extensions available so 
> that a sample editor would have to "support" MIDI plugins?

Again no.  A host could still choose whatever they support.  However, 
for example, an audio host might support the audio extensions, a video 
host might support the video extensions, and a host that is midi capable 
the midi extensions.  If you are dealing with 20 or 30 extensions there 
for whatever reason, are you honestly going to have an end-user go 
through and say, ok this extension is present, this one is present, this 
one is not, crap my plugin won't work or will be missing a gui.

Do not get me wrong, as I have said repeatedly thus far, LV2 is nice and 
highly expandable, and I certainly don't want to change that, but that 
by itself will not make it usable for the end user.  Power and 
flexibility do not necessarily equate ease of use, and personally I do 
not see a reason why this could not have all three, it is close as it is 
and the only thing holding it back are clear definitions of what will 
and won't work where for an end user that doesn't require 20 minutes 
worth of work for each plugin to see if it SHOULD work.  This has much 
less to do with the technical requirements of the spec, and much more to 
do with looking down the road and realizing that if this spec IS fully 
taken advantage of, things might very well get messy.

        Seablade