[LAD] [ANN] LV2 beta3
fons at kokkinizita.net
Wed May 9 10:21:31 UTC 2007
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
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.
Follie! Follie! Delirio vano è questo !
More information about the Linux-audio-dev