[sharing for requesting help] trying to make a feedback delay network in gen~
Hey,
Feedback delay network is documented here : https://ccrma.stanford.edu/~jos/cfdn/Feedback_Delay_Networks.html
It seems to be like a lot of delay lines in parallel that are fed back into each other.
My skills in math/dsp are limited, so i assumed that the matrix at the top of the figure "Order 3 Feedback Delay Network." is just meaning that all sounds are summed up. But maybe i'm wrong ?..
There is a really cool fdn~ object in PureDatak, i'm trying to "replicate" it in gen~.
Of course as the pd one has inners guts that create (nearly) any number of delay lines, it's not the same, but it still can be cool i think.
I'm not sure how to do this. Is it like this ?
Noone, really ? :/...
is that topic complicated for everyone, or am i really on that much of a bad track ?..
fdn~ is inside the creb lib http://sourceforge.net/projects/pure-data/files/libraries/creb/
or here http://zwizwa.be/darcs/creb/
Also FWIW Pluggo for Live has a Feedback Network patch you might want to look at.
@raja : i'm trying to translate the fdn~ from Pd to max also, see that thread : https://cycling74.com/forums/trying-to-compile-only-2-errors-left/
but probably better not start from there, i completely bonked the source. The only useful things i learned with that so far is that -it seems possible, and -you need to enforce the variant -fnested-functions in the "other c flags" field.
@Rick : let me link to the fdn~ source direclty, if i may ! http://zwizwa.be/darcs/creb/modules/fdn~.c and didn't know that pluggo thing
there is also an example of feedbak delay network inside a reverb in gen~, in the example/gen folder. it's the gigaverb~. From that and other sources, i inferred that the math for feedback delay networks includes substracting some of the delay lines, and adding others and feed a different result in each feedback delay line, and maybe calculating feedback coefficients a little more carefully. So there is math needed and that simple attempt certainely is not close to that.
Thanks !
(i try a lot.)
You're doing gods work again, raja.
wow. thanks a lot ... incidentally, i was working on it *a little* yesterday, and weeell i didn't even think about memset to system_newptr etc... now that i look at your source it seems a looot more work than what i had anticipated T_T
if i may allow myself some questions...
* you added fonction declarations for all the functions, is that just cleaner programming method or required in Max vs not in Pd ?
* you removed all the "static" casting (if i understand well, those things are called typecasting right ?..) of functions, i don't understand why there where "static" to begin with...
* i don't understand when you need to use t_double or double.
* You melted together the fdnctl and fdn struct, is that required for Max vs Pd ? or again cleaner (or your prefered) programming workflow ?
nice ! thanks for the infos.
re:functions declarations , from what i understood one needs to declare a function before it is used in another function - but the header lines are only a direct reference to the definition, so it counts as declaration (the compiler sees the header, then looks for function def in the code i guess, before going to next header) ; in the end if you define all the functions before they are used it should be fine ? :)
And i completely get the "overwhelmingly irritating" part, although it will be a delight to know about your progression in this thing ;D
this is greater than awesome thanks so much !! soooooo cool !!!
lin and exp seem to work as they should here !
...but you'll pollute us with attachments once things start working out, right?
So you're saying every samouraï should be a swordsmith as well ? >:D
On a more related note, i noticed that when i try something like lin 32 10 1015, or anything with a long delay line, it doesn't seem to work well. Well i'm not sure how it should work, but sound fades all of a sudden. Is it related to the clamp mistake you were talking about ? It's a behaviour that i encountered in PD as well. If this is a mistake in the original PD external, it could be maybe worht it to send the updated version to the pd list or whatever ?
hm just gave a look at original pd c file and they don't have this ClAMP function, neither the typo you made. But maybe adding a clamp would be beneficial for the pd version too ? maybe the clamping would be necessary for the bug i'm talking about too ?