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

[Matt Barber]

OK, looking at the OOURA code, the init routine has this:

========================
static int ooura_init( int n)
{
    n = (1 << ilog2(n));
    if (n < 64)
        return (0);
========================


then later in the fft/ifft routine:

========================
     if (!ooura_init(2*n))
        return;
========================

and rfft:
========================
    if (!ooura_init(n))
        return;
========================



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.
> (
> http://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_fft_fftsg.c
> ).
>
> 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 at 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 at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151016/3fca0383/attachment.html>