<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">Hi list,</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I've never seen this before in other versions of Pd. Anyone else get this behavior?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">Matt</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div>