Re: [LAD] [ANN] LV2 beta3

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.

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.

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.

4. There are 'audio rate' and 'control rate' ports, but no 'init
   time' ports. How are plugins supposed to discover initialisation
   parameters ?

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.

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).

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.

   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.

-- 
FA
Follie! Follie! Delirio vano è questo !
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo.cgi/linux-audio-dev