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.
Pd also has the option of using the FFTW3 library by Thomas Grill, which on a surface reading doesn’t seem to have a block boundary. But I can’t be sure w/o trying it. Of course this would require a manual compiling of Pd.
Not sure why the mayer fft lib was removed, but this is one of the few instances of Pd breaking older patches. Maybe this needs to be a dev request? At the very least print an error to the Pd window.
-Rob
P.S - I have a C++ version of the old mayer_fft that I could probably wrap into a Pd object if it seems like this is a big enough problem.
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.