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
On 10/16/2015 03:50 AM, Matt Barber wrote:
Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform -- it just passes the signal through unchanged.
isn't that what is expected of a 1 point FFT? (32bits == 4 bytes == sizeof(float)).
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.
so you meant 32 bytes (8 samples * 4 bytes each)?
or 32pins aka points (as in [block~ 32])?
gfmrdsa IOhannes
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 zmoelnig@iem.at wrote:
On 10/16/2015 03:50 AM, Matt Barber wrote:
Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform
--
it just passes the signal through unchanged.
isn't that what is expected of a 1 point FFT? (32bits == 4 bytes == sizeof(float)).
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.
so you meant 32 bytes (8 samples * 4 bytes each)?
or 32pins aka points (as in [block~ 32])?
gfmrdsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
laptop baby
On Oct 16, 2015, at 5:12 PM, Matt Barber brbrofsvl@gmail.com 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 zmoelnig@iem.at wrote: On 10/16/2015 03:50 AM, Matt Barber wrote:
Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform -- it just passes the signal through unchanged.
isn't that what is expected of a 1 point FFT? (32bits == 4 bytes == sizeof(float)).
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.
so you meant 32 bytes (8 samples * 4 bytes each)?
or 32pins aka points (as in [block~ 32])?
gfmrdsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 jaime.oliver2@gmail.com wrote:
laptop baby
On Oct 16, 2015, at 5:12 PM, Matt Barber brbrofsvl@gmail.com 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 zmoelnig@iem.at wrote:
On 10/16/2015 03:50 AM, Matt Barber wrote:
Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform
--
it just passes the signal through unchanged.
isn't that what is expected of a 1 point FFT? (32bits == 4 bytes == sizeof(float)).
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.
so you meant 32 bytes (8 samples * 4 bytes each)?
or 32pins aka points (as in [block~ 32])?
gfmrdsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
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 <brbrofsvl@gmail.com> wrote:
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 jaime.oliver2@gmail.com wrote:
laptop baby On Oct 16, 2015, at 5:12 PM, Matt Barber brbrofsvl@gmail.com 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 zmoelnig@iem.at wrote:
On 10/16/2015 03:50 AM, Matt Barber wrote:
Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform -- it just passes the signal through unchanged.
isn't that what is expected of a 1 point FFT? (32bits == 4 bytes == sizeof(float)).
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.
so you meant 32 bytes (8 samples * 4 bytes each)?
or 32pins aka points (as in [block~ 32])?
gfmrdsa IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
IOhannes m zmölnig -
Jaime E Oliver -
Jonathan Wilkes -
Matt Barber