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