[LAD] [ANN] LV2 beta3

Dave Robillard drobilla at connect.carleton.ca
Thu May 10 18:19:48 UTC 2007


On Thu, 2007-05-10 at 13:49 -0400, Thomas Vecchione wrote:
> > Tie in?
> 
> Tie someone into a specific distribution because that is the first one 
> they tried and had something they liked.
> 
> > This is FLOSS, right? Nobody gets to tell people what to do or not 
> > in the end. So if anyone wants to create 'arbitrary' extensions, 
> > he will. No profiles, no nothing change that.
> > 
> 
> EXACTLY my point.  When do they cease being arbitrary extensions and 
> instead be something a bit more structural for those programming the 
> host to have a basic idea of what they should do to support the majority 
> of plugins.

Seems there's a bit of confusion here.

"Extensions" usually include, if anything at all, a single header file
and maybe a bit of data in a .ttl file (though usually you only care
about what's in the plugins data file anyway).  Extensions of the simple
"function with more parameters" kind don't require any additional code
at all (you just dlsym your symbol and use it as specified).

For a host to support an extension, it can include everything it needs
in the host itself.  Since this is a specification (and not a specific
library interface), this is the best way of doing things.

Translation:  no "tie in" here.

There is the possibililty of helper libraries to make dealing with
extensions (or plugins, or anything), but that's par for the course.
Apps depending on libraries is business as usual, and app authors can
handle the situation however they please.

I still fail to see what this "profile" idea actually entails, in
concrete terms... I suspect it doesn't mean anything at all ;) As Lars
points out, trying to tell everyone what to do isn't worth the effort,
and is contrary to the whole point here anyway.  I'm not sure why anyone
would want to bother trying to come up with arbitrary definitions of
feature set combinations and slapping a "profile" name on it.  What's
the point?  Support the features you can/want to support..

That said, this is purely a documentation issue.  A nice central
location for finding what's out there in LV2 land would be useful.  A
wiki is probably the only thing that's feasible, unless someone wants to
maintain something more custom.

-DR-





More information about the Linux-audio-dev mailing list