Re: [LAD] [ANN] LV2 beta3

On Wed, May 09, 2007 at 12:36:34PM +0200, Lars Luthman wrote:

> On Wed, 2007-05-09 at 12:21 +0200, Fons Adriaensen wrote:
>
> > 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.

There is no reason to assume that plugins will always be used in
a Jack client. Fractional rates are required because resample
ratios often can't be expressed as a float or double. It's a
problem with the libsamplerate API as well.
>
> > 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.

See his comments in this.
 
> > 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.

So a plugin writer can't count on it.

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

Again, of no use it you can't count on it being present.

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

Same remark as the two above, and I wonder how it can be done at all.
Part of the solution would be to have a period or frame counter as parameter
to each run(). It would at least allow a plugin to discover wich run() calls
to its instances belong to the same period, and which is the first one for a
period. Trivial to implement and there is no good reason why it shouldn't be
there by default. But it's only part of what is required, it doesn't define
which instances form a group in the first place. A single unique group ID
would do. Again very simple to implement as standard.

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

Again you can't count on it being implemented. And a callback for each
parameter change doesn't solve the problem - in many cases you want to
handle all changes together because they modify the same internal data
and you don't want to redo the possibly complex calculations each time.
What's so difficult about setting a flag when a parameter is modified ?
But the best solution is to do away with static control values and present
all control changes as timestamped events.

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

Again, if you can't count on it, it's not very useful.

> > 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,

And that is the problem. It is much too easy both on hosts and plugins.
I really see no reason for not supplying an essential parameter such as
period size in the initialisation call. It's as fundamental as sample
rate. OK, some algos don't need it, but there are many that don't need
the sample rate either. Same for process priority and group ID.
All of this is trivial to ignore if you don't need it, but essential
in some cases.

*** These things should not be optional. ***

And why not present *all* control data as timestamped events from the
start ? In most cases there will be just one value for the start of the
period. Is this soooo difficult for a plugin writer to deal with ?
A plugin always has the simple option to ignore timestamps and just use
the last updates for the entire current period. You could even write a
simple wrapper library to present it with conventional control values
if it wants just those.

> but that wasn't the intention. The point is that it's easy to extend.

Optional support for fundament things is not a solution.

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

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