[LAD] [ANN] LV2 beta3

[Thorsten Wilms]

On Thu, May 10, 2007 at 08:51:22AM -0400, Thomas Vecchione wrote:
> 
> 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.

How about waiting a bit what extensions appear at all? 
Can't make meaningful plans for profiles or whatever beforehand, 
anyway.

 
> 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.

For the common user, hosts and plugin collections should be part 
of the distribution he uses. Ideally host packages would recommend 
plugin collections, but I only know that feature from Debian.
Anyway, the issue of the user having to check what works where 
doesn't has to appear in this case.

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.


> 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.

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.


-- 
Thorsten Wilms

Thorwil's Design for Free Software:
http://thorwil.wordpress.com