Forums > MaxMSP

pfft~ bins

December 13, 2010 | 9:42 pm

Hi, list,
Maybe it’s a stupid question, but haven’t figured it out this morning…
It’s about the bins or the third outlet of fftin~ object (in pfft~).

Say fft size is N, shouldn’t the real FFT have bins all the way from 0 to N/2?

Here fftin~ only gives bins from 0 to N/2-1, missing the highest frequency bin?

Thanks in advance

December 14, 2010 | 11:14 am

well, because it starts at 0 …. just count:

fft 1024 -> 0 … 511 ==512 values.


December 14, 2010 | 2:07 pm

In pfft~ the nyquist bin in the fft is zeroed on input and output to make everything neat (you never see this value). Similarly, there should not actaully be an imag value for the DC bin (DC and nyquist are real-valued only) but it is simpler to deal with N/2 pairs rather than (N/2 +1) real values and (N / 2 -1) imag values.

Most of the time this doesn’t matter. If it really matters to you you can try the old-school fft~ approach and roll your own overlapping scheme – it’s a bit of a pain. fft~ also only goes up to 4096 points though so you can’t do more than that and keep the nyquist bin. In my experience the number of cases where this will make a difference are very few, and mostly relate to fft processing with no window function….



December 15, 2010 | 6:48 pm

Thanks Alex for the detailed explanation, yeah I was thinking why it kept the DC bin and not the Nyquist bin.

Much clearer now :)

Viewing 4 posts - 1 through 4 (of 4 total)