Subject: RE: [linux-audio-dev] Extending LADSPA to support Non-Causal Plugins
From: Richard W.E. Furse (richard_AT_muse.demon.co.uk)
Date: Sat Oct 28 2000 - 18:02:39 EEST
Thanks for the notes, all excellent points:
1. Yep, as you say, transport must be provided by the host. I'll make this
clearer. The const is there to protect the plugin writer from attempting to
change the InputLength data - hopefully LADSPA is currently fairly kind to
the programmer in this respect.
2. Interesting one on re-entrance and I agree with your thinking. I'd have
thought this is entirely the host's problem and in general feedback cannot
be unravelled, for example, a non-causal delay plugin y[n]=x[n+1] fed back
on itself gives y[n]=y[n+1]=y[n+2]=y[n+3]=... which is clearly impossible
to compute and will lead to an infinite loop in the unbounded case. In the
bounded case behaviour is somewhat undefined but there is still no valid
result. I can think of a couple of functions that could be resolved (e.g.
y[n]=if(n<100)then(x[n+1])else(0)) but these rely on switching from
non-causal to causal behaviour (and not reverting unless the plugins do
clever things with block size). These "working" cases are few and far
between and off the top of my head I cannot think of anything really useful
musically. I suggest putting a warning in the API to bring this issue to
the attention of host programmers and otherwise leaving the problem alone -
unless people can think of example cases that would make it worth resolving
this.
3. Quite right, I missed a parameter. (I'd been thinking in C++ and forgot
the method would need the transport pointer as in your last solution.)
Thinking about it, perhaps the plugin pointer should be passed too. Not
sure...
I have a couple of other tweaks developing at the back of my mind. Nothing
major.
Cheers,
--Richard
-----Original Message-----
From: David Benson [SMTP:daveb_AT_idealab.com]
Sent: Friday, October 27, 2000 4:16 PM
To: Richard W.E. Furse
Cc: Linux Audio Developer Mailing List (E-mail)
Subject: Re: [linux-audio-dev] Extending LADSPA to support Non-Causal
Plugins
[...]
It is a bit confusing when you read about
the InputControlTransport as to whether that
object should be provided by the host or the plugin;
though the context makes it clear the host is responsible.
(I think that, since it is basically a seekable input stream
the const on connect_noncausal (..,const LADSPA_InputControlTransport*)
may be a bit confusing)
I'm generally concerned about the heavy reentrance
this might bring, since it seems quite possible
to tie things into an infinite loop (by having the
input_transport read from the same ladspa filter);
its not quite clear if the host or the plugin is responsible
for unravelling things. so we may want LADSPA_PROPERTY_NONREENTRANT
for less painful but less powerful plugin implementations
(that prevent hosts from tying loops in their plugins)
(maybe the bounded length stuff suffices though, i'm not sure...)
Also:
> unsigned long (*move_noncausal_inputs)(unsigned long Offset,
> unsigned long SampleCount);
is problematic.
[...]
or, if the whole userdata thing is too confusing,
unsigned long (*move_noncausal_inputs)(unsigned long Offset,
unsigned long SampleCount,
LADSPA_InputControlTransport *Transport);
- Dave
This archive was generated by hypermail 2b28 : Sat Oct 28 2000 - 18:27:48 EEST