[LAD] [ANN] LV2 beta3

[Thomas Vecchione]

> For the common user, hosts and plugin collections should be part 
> of the distribution he uses.


Oh I sincerely hope we are not going to tie people in like this, that 
would be a VERY bad thing IMO.

> 
> It might be far easier to list the supporting hosts for each plugin, 
> once the number of extensions outgrows the number of hosts. It's not 
> difficult to read a plain list.


But it is more work, and if that list grows at all then it is a lot of 
extra work.  Not only that, but we are dealing with open source, is 
someone going to go around to each individual project that exists, 
whether or not they know about it, and test each individual plugin that 
exists, whether or not we know about it?  Again this is VST support in 
linux as it currently stands all over again.  Someone asks me if a 
certain VST plugin is supported all I can answer is maybe.  And a list 
does exist for it, just usually doesn't have half the plugins people 
look for as it depends on others trying it and reporting it, and their 
exact configurations.

> Please recognise that a new standard needs a phase of experimentation. 
> You simply can't decide on every possible what-if and nail everything  
> down, as then nothing is ever pushed out the door.

I am fully aware of that, but the entire point of LV2 being so flexible 
is specifically so that the 'what-if' I am proposing CAN happen.  I 
(Personally) think it is foolish to build the spec specifically so that 
it can happen, and then ignore what will happen when it does.

What happens when arbitrary extensions are made by a handful of people, 
for a handful of plugins on a year by year basis.  In a couple of years 
you have significantly more than a handful of extensions.

Will it happen?  Who knows.  But, my understanding is that LV2 was 
written specifically so that the above COULD happen if it needed, and it 
is extremely easy to define new extensions.

If we want it to remain a 'standard' plugin format, we should plan for 
it being used to its capabilities and make sure some level of 
interoperability remains, and that that level is clear for the end-user 
to understand.

As I mentioned before I am tossing out my two cents in full 
understanding that it can be chosen to be extensively ignored, with 
every right, on the part of any or all of the developers.  I don't mean 
to offend any of them here, and I certainly don't take offense at folks 
disagreeing with me, just so that it is clear.

It is just my two cents based off my experience with helping people 
understand linux audio thus far and a major pitfall I see with building 
something extremely flexible and powerful but without any organization 
so those less technical saavy folks can understand it.

        Seablade