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