9 May
2007
9 May
'07
8:38 a.m.
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:
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.
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.
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