Re: [LAD] [ANN] LV2 beta3

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev