Re: [LAD] [ANN] LV2 beta3

> 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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
Received on Thu May 10 20:15:02 2007