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

Minimum FFT size is still not fixed in pd 0.48-1test3. I verified that 4 point works as expected for all FFT objects (fft~, ifft~, rfft~ and rifft~) if this conditional check is changed in function ooura_init(): "if (n < 64)" becomes "if (n < 4)" By the way I used a 16 point FFT to quickly test

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

hi, I'd like to pick up this thread after stumbling on it in the archive. For the same reason that Matt explained I'd like to see rfft~ working for small blocks of 4 to 32 samples. best, marius. 2015-10-19 22:08 GMT+02:00 Matt Barber : > ​Seems fine, since the 2-pt FFTs are

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

I'm not sure, but I think I had limited it to 64 because some older FFT package I was using had that limit. I'm not sure but I think the rfft objects require at least 4 points to work properly. So perhaps it would be OK to impose 4 as a minimum for all the FFT objects. In any case, there

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

OOURA's cdft and rdft function descriptions clearly state that FFT size 2 is the minimum. Maybe the data permutation is trickier for block size < 64. The old arrangement was weird, you don't get an array with complex numbers, but the imaginary output appearing in reversed order after the real

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

I meant 32 points, sorry. You can usually assume I'm typing with a crying baby in my lap. :) On Fri, Oct 16, 2015 at 4:14 PM, IOhannes m zmölnig wrote: > On 10/16/2015 03:50 AM, Matt Barber wrote: > > Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform > --

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

laptop baby On Oct 16, 2015, at 5:12 PM, Matt Barber wrote: > I meant 32 points, sorry. You can usually assume I'm typing with a crying > baby in my lap. :) > > On Fri, Oct 16, 2015 at 4:14 PM, IOhannes m zmölnig wrote: > On 10/16/2015 03:50 AM, Matt

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

It's actually twins. It's a complex situation; I don't yet know which is real and which imaginary. On Fri, Oct 16, 2015 at 5:29 PM, Jaime E Oliver wrote: > laptop baby > > On Oct 16, 2015, at 5:12 PM, Matt Barber wrote: > > I meant 32 points,

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

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

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

Is there something like a real-life [trigger] you use to keep track of their ordering? -Jonathan On Friday, October 16, 2015 5:39 PM, Matt Barber wrote: It's actually twins. It's a complex situation; I don't yet know which is real and which imaginary. On Fri,

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

Sorry I checked your patch again. I get the same behavior. I had an older version of Pd I was using. Yes, I just noticed this too. It appears OOURA limits the calculation to a block size of 32 or higher. Why? The code is so horribly documented I’d rather not even try to figure it out.

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

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))

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

lt;pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>> > Subject: Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX > > > Is there something like a real-life [trigger] you use to keep track of their > ordering? > > -Jonathan >

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

Looking closer, it appears the OOURA fft has special routines for n<64... but it uses those routines regularly as subroutines in larger ffts. In any case it looks like the smaller block sizes are intended to be usable in the code itself, but Miller must've had a reason not to trust them. Here's

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

; *To: *Matt Barber <brbrof...@gmail.com>, Jaime E Oliver < > jaime.oliv...@gmail.com> > *Cc: *Pd-List <pd-list@lists.iem.at> > *Subject: **Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX* > > > Is there something like a real-life [trigger] you use to keep track of > t

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

st <pd-list@lists.iem.at> Subject: Re: [PD] fft~ bug in Pd-0.46-7-64bit.app on OSX Is there something like a real-life [trigger] you use to keep track of their  ordering? -Jonathan ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE a

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

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