<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">OK, looking at the OOURA code, the init routine has this:</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">========================</div><div class="gmail_default" style=""><div class="gmail_default" style="font-family:verdana,sans-serif">static int ooura_init( int n)</div><div class="gmail_default" style="font-family:verdana,sans-serif">{</div><div class="gmail_default" style="font-family:verdana,sans-serif"> n = (1 << ilog2(n));</div><div class="gmail_default" style="font-family:verdana,sans-serif"> if (n < 64)</div><div class="gmail_default" style="font-family:verdana,sans-serif"> return (0);</div><div style="font-family:verdana,sans-serif">========================</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">then later in the fft/ifft routine:</div><div style="font-family:verdana,sans-serif"><br></div><div style="font-family:verdana,sans-serif">========================</div><div style=""><div style=""><font face="verdana, sans-serif"> if (!ooura_init(2*n))</font></div><div style=""><font face="verdana, sans-serif"> return;</font></div><div style=""><font face="verdana, sans-serif">========================</font></div><div style=""><font face="verdana, sans-serif"><br></font></div><div style=""><font face="verdana, sans-serif">and rfft:</font></div><div style=""><font face="verdana, sans-serif">========================</font></div><div style=""><font face="verdana, sans-serif"><div> if (!ooura_init(n))</div><div> return;</div><div>========================</div><div><br></div><div><br></div><div><br></div><div>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.</div><div><br></div><div><br></div></font></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 16, 2015 at 5:33 PM, katja <span dir="ltr"><<a href="mailto:katjavetter@gmail.com" target="_blank">katjavetter@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If I understand the fft files correctly OOURA is now the default, but<br>
'disguised' as mayer fft so the old API should remain valid.<br>
(<a href="http://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_fft_fftsg.c" rel="noreferrer" target="_blank">http://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_fft_fftsg.c</a>).<br>
<br>
Indeed I get the same result for Matt's test patch with Pd 0.46-5<br>
which is on my system. Sinusoids for block size 8 and 16, instead of<br>
spectrum points.<br>
<br>
A while ago I've been reading in OOURA fft code and what I remember<br>
is, Pd uses its mixed radix functions. Not sure about it though.<br>
<br>
Katja<br>
<div><div class="h5"><br>
<br>
On Fri, Oct 16, 2015 at 10:00 PM, Robert Esler <<a href="mailto:robert@urbanstew.org">robert@urbanstew.org</a>> wrote:<br>
><br>
> 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.<br>
> 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.<br>
> You could also download the old library and recompile Pd, but I doubt it’s worth it.<br>
> -Rob<br>
> -------<br>
> Hi list,<br>
><br>
> There's either a major bug in the [fft~] objects in Pd-0.46.7 (64bit OSX)<br>
> or I'm going crazy. I'd love to see if others can reproduce it.<br>
><br>
> Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform --<br>
> it just passes the signal through unchanged. [ifft~] does the same. The<br>
> [rfft~]-[rifft~] is a little more complicated -- it passes signal through<br>
> but zeroes out the last N/2 for [block~] sizes less than 64.<br>
><br>
><br>
> See the attached patch, which only shows [fft~]. The saved contents of the<br>
> tables on opening are the results for [block~ 8] on my machine, for<br>
> quarter-nyquist at 44100.<br>
><br>
> I've never seen this before in other versions of Pd. Anyone else get this<br>
> behavior?<br>
><br>
> Matt<br>
</div></div>> _______________________________________________<br>
> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
</blockquote></div><br></div>