[LAD] [ANN] LV2 beta3

Lars Luthman lars.luthman at gmail.com
Wed May 9 10:36:34 UTC 2007


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20070509/4872d961/attachment.pgp>


More information about the Linux-audio-dev mailing list