On Wed, 2007-05-09 at 12:21 +0200, Fons Adriaensen wrote: > On Wed, May 09, 2007 at 02:53:33AM +0100, Steve Harris wrote: > > > The current iteration of the LV2 specification seems to have settled > > down, and there are a significant number of implementations now, so, > > assuming that there's no problems found with the current spec I > > propose to rename it as 1.0 in a few weeks time. > > > > Background - http://lv2plug.in/ > > Some comments / potential problems. > > > 1, Only integer sample rates. This should be at least a fraction > of two integers.
Given that JACK only supports integer sample rates I don't think that this is a big deal. On the other hand I can't really see any disadvantages with having it as a float or double, so if there are any compelling reasons for doing that I think I agree. > 2. Plugins are expected to have a fixed set of ports. There are > cases where a plugin can only decide wich ports it will need > after being instantiated. This can be done using an extension. I think Nedko Arnaudov has already specified one for dynamically appearing and disappearing ports. > 3. Plugins may want to delegate some of the processing to threads > running just below the audio thread priority, so this priority > is an essential initialisation parameter. Can be done as a HostFeature. > 4. There are 'audio rate' and 'control rate' ports, but no 'init > time' ports. How are plugins supposed to discover initialisation > parameters ? Can be done as a HostFeature. > 5. If a plugin is instantiated multiple times to operate on > multi-channel data it may want to share control ports within > such a group, if only to optimise the (possibly complex and CPU > intensive) code that maps external control values to internal > data. I see no way to form such groups. Can be done as a HostFeature. > 6. The only way for plugins to discover if a control port value > has changed is to keep a copy and compare all values during > each run(). See also (7). This isn't all that expensive, but if a plugin really really needed a new callback to be executed by the host when a control port value changed it could be done as a HostFeature. > 7. There is no fixed audio period. Host may call run() for any > number of samples. This is probably meant as a way to allow > hosts to change control values at arbitrary points, but this > defeats the purpose of having control rate in the first place. > It's a typical 'let's be lazy' solution that does not solve > the original problem except in some simple cases. > > Some algorithms can't be written to run efficiently - or at > all - in such circumstances. Plugins should be run() with > fixed block size. Can be done as a HostFeature. In fact, there are two such extensions already - see http://tapas.affenbande.org/wordpress/?page_id=53 > If plugins are to know that certain things need to happen at > particular offsets into a processing period then they should > be passed this info as a list of events (timestamed relative > to the start of the period), and be allowed to deal with that > in the most appropriate way, which may well be very different > to slicing up the audio period. > > Some algorithms may even require that such events are presented > some number of samples ahead of their due time. This of course > forces the plugin to queue them internally, but in some cases > that's the only way to do it. > > What is needed here is a generic way to pass a list of time- > stamped event to a plugin via a control rate port, and then > let the plugin deal with them as it sees fit. Can be done as a port class. In fact, this is pretty much how the MIDI extension works - see http://ll-plugins.nongnu.org/lv2/ext/MidiPort The core LV2 spec doesn't support much more than the LADSPA spec, but that wasn't the intention. The point is that it's easy to extend. --ll
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev
