forgot to send to list, sorry
---------- Forwarded message --------- From: José de Abreu abreubacelar@gmail.com Date: Sex, 25 de jan de 2019 15:16 Subject: Re: [PD] what fdn~ does? To: Alexandre Torres Porres porres@gmail.com
I don't know how to use the object, but you can read about what is FDN here, and if i remember well one of revN~ objects from miller uses this approach to make reverb
https://ccrma.stanford.edu/~jos/pasp/Feedback_Delay_Networks_FDN.html
Em Sex, 25 de jan de 2019 14:14, Alexandre Torres Porres porres@gmail.com escreveu:
Hi, I'd like to figure out what the [creb/fdn~] object does and how I can control it.
The documentation is too simple and I don't get what the code does. BTW, code says it's a "a feedback delay network (reverb tail) using a householder reflection feedback matrix (In - 2/n 11T)".
Has anyone ever used this object and could help me out?
cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
And to be more complete, this other link talks about FDN reverberation and talks about that householder matrix fdn~ uses
https://ccrma.stanford.edu/~jos/pasp/FDN_Reverberation.html
Em Sex, 25 de jan de 2019 15:19, José de Abreu abreubacelar@gmail.com escreveu:
forgot to send to list, sorry
---------- Forwarded message --------- From: José de Abreu abreubacelar@gmail.com Date: Sex, 25 de jan de 2019 15:16 Subject: Re: [PD] what fdn~ does? To: Alexandre Torres Porres porres@gmail.com
I don't know how to use the object, but you can read about what is FDN here, and if i remember well one of revN~ objects from miller uses this approach to make reverb
https://ccrma.stanford.edu/~jos/pasp/Feedback_Delay_Networks_FDN.html
Em Sex, 25 de jan de 2019 14:14, Alexandre Torres Porres porres@gmail.com escreveu:
Hi, I'd like to figure out what the [creb/fdn~] object does and how I can control it.
The documentation is too simple and I don't get what the code does. BTW, code says it's a "a feedback delay network (reverb tail) using a householder reflection feedback matrix (In - 2/n 11T)".
Has anyone ever used this object and could help me out?
cheers _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Em sex, 25 de jan de 2019 às 15:24, José de Abreu abreubacelar@gmail.com escreveu:
if i remember well one of revN~ objects from miller uses this approach to
make reverb
ok, now I'm curious, which one? Can we confirm it is an actual "FDN" approach? It seems Miller has an important paper describing FDN for reverb :)
And, yeah, I've checking those sources already and I could get the gist of it... but it'd be quite better if the author or someone who's been using this object a lot could better clarify how to deal with it.
cheers
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"?
Em sex, 25 de jan de 2019 às 18:03, Alexandre Torres Porres < porres@gmail.com> escreveu:
Em sex, 25 de jan de 2019 às 15:24, José de Abreu abreubacelar@gmail.com escreveu:
if i remember well one of revN~ objects from miller uses this approach to
make reverb
ok, now I'm curious, which one? Can we confirm it is an actual "FDN" approach? It seems Miller has an important paper describing FDN for reverb :)
And, yeah, I've checking those sources already and I could get the gist of it... but it'd be quite better if the author or someone who's been using this object a lot could better clarify how to deal with it.
cheers
- 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....
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
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
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
-
Alexandre Torres Porres -
José de Abreu -
Julian Brooks -
Peter P.