Nice sleuthing Holmes

On Tue, 29 Jan 2019 at 01:43, Alexandre Torres Porres <porres@gmail.com> wrote:
I guess "bingo"? https://ccrma.stanford.edu/~jos/pasp/First_Order_Delay_Filter_Design.html

Em seg, 28 de jan de 2019 às 22:54, Alexandre Torres Porres <porres@gmail.com> escreveu:

Em seg, 28 de jan de 2019 às 18:45, Peter P. <peterparker@fastmail.com> escreveu:
* Alexandre Torres Porres <porres@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. 


cheers




 
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list