[PD] Fwd: what fdn~ does?

Alexandre Torres Porres porres at gmail.com
Tue Jan 29 01:54:09 CET 2019

Em seg, 28 de jan de 2019 às 18:45, Peter P. <peterparker at fastmail.com>

> * Alexandre Torres Porres <porres at gmail.com> [2019-01-28 20:10]:
> > I guess I'm figuring something out, but the secondary inlets are still
> not
> > clear to me, they set the decay time, but why is there a "low" and
> "high"?
> Could it be that decay times are different for high and low frequencies
> and that these two are divided by a cutoff frequency? Just guessing....

Sort of... I finally made some sense of the code. it seems there's a 1pole
filter whose parameters depend on these low/high values and the delay
length! In the comment of the code we find a filter equation, something
like:* "yn = (2*gl*gh ) / (gl+gh) x + (gl-gh) / (gl+gh) y[n-1]" *- where
*gl* & *gh* are derived from these low and high values. Here's a code
simplification of it

    *for*(i = 0; i < x->x_ctl.c_order; i++){

        gl = pow(10, -0.003 * x->x_ctl.c_length[i] / low);

        gh = pow(10, -0.003 * x->x_ctl.c_length[i] / high);

        x->x_ctl.c_gain_in[i] = 2*gl*gh / (gl+gh);

        x->x_ctl.c_gain_state[i] = (gl-gh) / (gl+gh);

I don't really get how this filter fully works yet, but I can sort of get
the gist of it. I'm now in the quest to find what is the source of this
filter, and maybe try it out independently to see how it behaves. But
perhaps a more sophisticated method, with a settable crossover frequency
could be used instead.

And yeah, it seems vanilla's [rev2~] and [rev3~] are implementations of
feedback delay networks like it's been said here on this thread.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20190128/76850fbb/attachment-0003.html>

More information about the Pd-list mailing list