[PD] fft~ bug in Pd-0.46-7-64bit.app on OSX

[Robert Esler]

  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