If I understand the fft files correctly OOURA is now the default, but 'disguised' as mayer fft so the old API should remain valid. (http://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_fft_fftsg....).
Indeed I get the same result for Matt's test patch with Pd 0.46-5 which is on my system. Sinusoids for block size 8 and 16, instead of spectrum points.
A while ago I've been reading in OOURA fft code and what I remember is, Pd uses its mixed radix functions. Not sure about it though.
Katja
On Fri, Oct 16, 2015 at 10:00 PM, Robert Esler robert@urbanstew.org wrote:
As far as I know Pd stopped using the mayer fft library in .46, which is probably why this is new behavior. I only get what you’re experiencing with a block size of 8. Otherwise, it seems to perform as expected. To really understand if this is a bug or not is to know which fft library is being used for OS X. My guess is it’s the OOURA but it’s not clear from looking at [fft~] object code that comes with distribution. You could also download the old library and recompile Pd, but I doubt it’s worth it.
-Rob
Hi list,
There's either a major bug in the [fft~] objects in Pd-0.46.7 (64bit OSX) or I'm going crazy. I'd love to see if others can reproduce it.
Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform -- it just passes the signal through unchanged. [ifft~] does the same. The [rfft~]-[rifft~] is a little more complicated -- it passes signal through but zeroes out the last N/2 for [block~] sizes less than 64.
See the attached patch, which only shows [fft~]. The saved contents of the tables on opening are the results for [block~ 8] on my machine, for quarter-nyquist at 44100.
I've never seen this before in other versions of Pd. Anyone else get this behavior?
Matt _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list