Subject: Re: Feedback in LADSPA (was Re: [linux-audio-dev] New LADSPA Version - Issues Resolved?)
From: Jarno Seppanen (jams_AT_cs.tut.fi)
Date: pe maalis 10 2000 - 14:42:11 EST
Paul Barton-Davis <pbd_AT_Op.Net> writes:
> >The simplest case: one plugin with external feedback
> >
> > +----------+
> > +->| plugin |>-+
> > | +----------+ |
> > +----------------+
>
> Why would a host ever do this ? Plugins don't call connect_port(), so
> the host would be responsible for this, and I can no reason why it
> would ever want to do this. Can you ?
The host might do that under sadistical control from the user. :-) Seriously,
that was an "academical" construct meant to show that LADSPA can be used to
implement cycles in plugin networks.
Now here is a more real-world case where feedback might be of interest:
input --> adder --> delay -+-> output
^ |
| |
+---< LPF <-----+
Two buffers needed: A (written by "input" and "adder"), B (wr. by "delay")
David Olofson <david_AT_gardena.net> writes:
> On Thu, 09 Mar 2000, Jarno Seppanen wrote:
> > > Feedback loops in the host's network are beyond the scope of this API. The
> >
> > Stressing out: this does not need changes in the current API!
>
> Not completely true, if the feedback delay time is to be accurate.
What do you mean by accurate? It is sample accurate in the sense that the
user knows how much additional pure delay will be in his loops (that's always
exactly one buffer's length, provided that the plugin execution order is
appropriate).
Who defines the "ideal" or "desired" delay inside a feedback? We, as
programmers, don't! It's the *user* who defines how much delay he wants. And
the user cares only about the sound the thing produces.
> Plugins have to specify a processing delay value. Sounds pretty
> simple, but there is one problem; the delay may depend on control
> inputs...
All in all, this would only be needed in order to tell it to the user. Or how
would you utilize such values otherwise? You could only tell the user the
exact number of samples your feedback signal is delayed, but I argue that the
user doesn't care.
Alexander Ehlert <ehlert_AT_phys.unsw.edu.au> writes:
> Another problem is that the minimum feedback delay is bound to the process
> buffer size. No data processed -> no feedback :) Aah, analogue is so much
> easier... And changing feedback delay times in realtime is surely
> complicated, just imagine some really sick configurations were some
> feedbacks could be depended from others...
I don't understand. Could you provide examples of what you mean?
> Definitly a NO for feedback in LADSPA. Probably even for MUCOS? Anyway I
> think, stuff like that should be done within one plugin.
IMHO banning feedback loops in plugin networks is a VERY bad idea, especially
when it is already trivial to permit them. I think that if a user wants to
add a cycle in his network, he has all the rights to do that! He must only
know that the delays may not match at first attempt, but banning the whole
attempt because of this is...is...censorship :-)
I don't insist on having feedback in order to implement something like an IIR
filter but for encouraging experimenting! Have a feedback around a delay line
and add a dynamic range compressor to the feedback path! Or a waveshaper! Or
a vocoder! It doesn't matter if there is 1, 5 or 50 milliseconds of delay as
long as I can hook the compressor to the feedback loop. Implementing all of
these examples inside different dedicated plugins makes experimenting in this
sense almost impossible.
Comments on the above? I don't intend to have a war but to spur discussion!
Let's add one more of these: :-)
-- -Jarno
This archive was generated by hypermail 2b28 : su maalis 12 2000 - 09:14:06 EST