On Tue, 2006-06-20 at 08:51 +0100, Steve Harris wrote: > There's been little news on the LV2 front here recently, all the disucssion > seems to have taken place on IRC, so a quick update: > > Theres now a website: http://lv2plug.in/ as of a couple od days ago, > thanks to Thorsten Wilms which has links to drafts of the C header file > and RDF/Turtle schema. Please read the formal specs and comment. > > Following discussion on the l-a-u list and hard work by a lot of people > there's a logo. Please don't discuss the logo except to praise it ;) > choosing one was quite involved. Various generic forms (black on white > etc.) will be availble on the website in due course. > > TODO list: > * Finalise the technical aspect of the spec, get interested parties to > confirm that it meets thier needs (or at least doesn't prevent them). > > * Write human language specification to go with .h and .ttl explaining > how to use the spec, conventions etc. > > * Make sure there's a reasonable set of reference implementations and > examples. > > * Test the extension mechanisms. > > * Publish final spec, have tea and cakes etc.
* Figure out what to do about plugin latency I think plugins with latency should be required to provide latency information to a control output port (like the convention for LADSPA). The best way to do this IMO is to list the port in the RDF file, since reserving a port symbol is pretty dirty and un LV2ey.. there's probably other 'special' ports that will come along due to extensions, and reserving their symbols is a bad slippery slope to step on to. I can make the plugin validating host check the latency primitively (eg run a single sample through the buffer) and fail if it isn't reported correctly, so we're sure the LADSPA latency woes are gone. -DR-