[PD] fft~ bug in Pd-0.46-7-64bit.app on OSX
brbrofsvl at gmail.com
Sat Oct 17 01:09:40 CEST 2015
OK, looking at the OOURA code, the init routine has this:
static int ooura_init( int n)
n = (1 << ilog2(n));
if (n < 64)
then later in the fft/ifft routine:
since these operate directly on samples in the signal vector, it will pass
signals in small blocks without performing dft. I don't know what this is
supposed to avoid. I've used fft in small block sizes before, and I can't
be the only one whose patches might be broken by this.
On Fri, Oct 16, 2015 at 5:33 PM, katja <katjavetter at gmail.com> wrote:
> If I understand the fft files correctly OOURA is now the default, but
> 'disguised' as mayer fft so the old API should remain valid.
> 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.
> On Fri, Oct 16, 2015 at 10:00 PM, Robert Esler <robert at urbanstew.org>
> > 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
> > 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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pd-list