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 - 19:29:23 EEST
Dang you're starting to get into MN's specialised territory here - MN
resolves the network described in your example (which incidentally includes
only causal plugins) automatically and rather efficiently. I was hoping to
stay off these subjects until I'd had time to publish a paper or two ;-)
[And if you lot think I'm short-changing you, MN's plugin model is
definitely NOT simple or generally compatible. Plus it does not allow
reverse!]
My instinct at this stage is to cite the S of LADSPA and observe that your
suggestions, though broadly valid, are in the same realm as multiple
data-types and events. I must concede that these suggestions do not REQUIRE
their use. However they will need quite a bit of refinement to be generally
useful and they risk confusing plugin (let alone host) programmers. I think
the whole concept of support for non-causality (or whatever we end up
calling it) is risking confusion already and I'm reluctant to make things
worse - IMHO the extra learning cost is justified only because of
applicability to editors.
I'm going to have to think some more about this.
Yep, multiple non-causal inputs are allowed by the current API - I did
think about putting a port parameter on the move_noncausal_inputs (and
removing the 's'). The current API does exactly when 99% of likely
non-causal plugins want in an efficient way and doesn't break the other 1%.
I'm open to argument on this if many real-world examples can be found.
--Richard
-----Original Message-----
From: David Benson [SMTP:daveb_AT_idealab.com]
Sent: Saturday, October 28, 2000 4:37 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
> 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.
..
I agree taht the host CAN and probably should do reentrance checking,
but it is insufficient for many uses, consider:
input---------------> mixer --------> delay +------> output
^ for 30-samples
| |
| |
+-- gain-down <---+
a not-very-inspired feedback loop
someone, somewhere, needs to force this system to
run at a block size of 30, or the delay needs special
care to allow full reentrance. (Even with that special care,
the stack size required will be O(num_samples_in_block / delay)
which is scary.)
so, i think in addition to NEEDS_BOUNDED_INPUT,
we also need a NoncausalPortHint: ``LADSPA_PROPERTY_HAS_BOUNDED_LATENCY''
to allow the host to compute the loop's block size,
the actual latency ought to be presented as a PortHint.
Or we could allow the latency to depend upon control port settings,
LADSPA_PROPERTY_HAS_LATENCY and
int (*get_latency) (LADSPA_Descriptor *instance,
int InputPortId,
int OutputPortId);
instread of declaring a permanent maximum.
(BTW are we going to allow multiple noncausal inputs -- i think we should
-- in which case the `connect_transport' needs PortId added to its param list; as you noted it definitely needs the descriptor added already)- Dave
This archive was generated by hypermail 2b28 : Sat Oct 28 2000 - 19:55:53 EEST