i am not comb filtering the fft data i'm interpolating/averaging it to smooth out the noise and see the actual filter response... done with the 1 block feedback delay... nice trick i made up while looking at your patch
I get a pretty ugly readout when I run your patch as is. It basically looks like a stream of running peaks, which I thought was a result of the FFT comb-filtering itself. But after looking at it again, the delay lines were shorter than the block size in the [pd fft] patches. After raising them, I get what I think you're seeing. Which, I must say, is quite nice! I don't understand why you're getting away with the short delay lines though?
But now I have two more questions after seeing it right. First, why are you using the [z~ 10] for the first spectrum table? It seems that if you don't use it, you get the reconstructed noise you're expecting. Also, since spectrum3 does what you expected, can you explain the difference between the two outlets of [vcf~]? I can't seem to find the documentation on that, and I don't know enough about filters to understand just by looking at the spectrums.
you only have to change the frequency range if you want to see the complete space... if you are interested in a filter you can let it at 44.1khz (or even 25k) and change the samplerate to 88,2khz the filter should look (almost) the same... but it seems that [notch] is not samplerate independent. so if you double the samplerate you have to divide the cutoff-frequency by the same amount to get the same graph
but my tests showed that a lot filters react poorly and act different on different samplerates and especially if you change the samplerate
Yep, sorry. I kind of brain-farted there. I think I just assumed your weird readouts were a result of downsampling, and then confused myself . And you're right, it does appear [notch] uses a hard-coded sample rate.