<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Sorry I checked your patch again. I get the same behavior. I had an older version of Pd I was using.<div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">-Rob<br class=""><div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><br class=""></div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class="">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.</div><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; " class=""><br class=""></div>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On Oct 16, 2015, at 4:09 PM, Matt Barber <<a href="mailto:brbrofsvl@gmail.com" class="">brbrofsvl@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><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 class=""></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" class="">========================</div><div style="font-family:verdana,sans-serif" class=""><br class=""></div><div style="font-family:verdana,sans-serif" class=""><br class=""></div><div style="font-family:verdana,sans-serif" class="">then later in the fft/ifft routine:</div><div style="font-family:verdana,sans-serif" class=""><br class=""></div><div style="font-family:verdana,sans-serif" class="">========================</div><div style="" class=""><div style="" class=""><font face="verdana, sans-serif" class=""> if (!ooura_init(2*n))</font></div><div style="" class=""><font face="verdana, sans-serif" class=""> return;</font></div><div style="" class=""><font face="verdana, sans-serif" class="">========================</font></div><div style="" class=""><font face="verdana, sans-serif" class=""><br class=""></font></div><div style="" class=""><font face="verdana, sans-serif" class="">and rfft:</font></div><div style="" class=""><font face="verdana, sans-serif" class="">========================</font></div><div style="" class=""><font face="verdana, sans-serif" class=""><div class=""> if (!ooura_init(n))</div><div class=""> return;</div><div class="">========================</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><br class=""></div></font></div></div></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Oct 16, 2015 at 5:33 PM, katja <span dir="ltr" class=""><<a href="mailto:katjavetter@gmail.com" target="_blank" class="">katjavetter@gmail.com</a>></span> wrote:<br class=""><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 class="">
'disguised' as mayer fft so the old API should remain valid.<br class="">
(<a href="http://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_fft_fftsg.c" rel="noreferrer" target="_blank" class="">http://sourceforge.net/p/pure-data/pure-data/ci/master/tree/src/d_fft_fftsg.c</a>).<br class="">
<br class="">
Indeed I get the same result for Matt's test patch with Pd 0.46-5<br class="">
which is on my system. Sinusoids for block size 8 and 16, instead of<br class="">
spectrum points.<br class="">
<br class="">
A while ago I've been reading in OOURA fft code and what I remember<br class="">
is, Pd uses its mixed radix functions. Not sure about it though.<br class="">
<br class="">
Katja<br class="">
<div class=""><div class="h5"><br class="">
<br class="">
On Fri, Oct 16, 2015 at 10:00 PM, Robert Esler <<a href="mailto:robert@urbanstew.org" class="">robert@urbanstew.org</a>> wrote:<br class="">
><br class="">
> 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 class="">
> 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 class="">
> You could also download the old library and recompile Pd, but I doubt it’s worth it.<br class="">
> -Rob<br class="">
> -------<br class="">
> Hi list,<br class="">
><br class="">
> There's either a major bug in the [fft~] objects in Pd-0.46.7 (64bit OSX)<br class="">
> or I'm going crazy. I'd love to see if others can reproduce it.<br class="">
><br class="">
> Basically, for [block~] sizes less than 32 bits, [fft~] doesn't perform --<br class="">
> it just passes the signal through unchanged. [ifft~] does the same. The<br class="">
> [rfft~]-[rifft~] is a little more complicated -- it passes signal through<br class="">
> but zeroes out the last N/2 for [block~] sizes less than 64.<br class="">
><br class="">
><br class="">
> See the attached patch, which only shows [fft~]. The saved contents of the<br class="">
> tables on opening are the results for [block~ 8] on my machine, for<br class="">
> quarter-nyquist at 44100.<br class="">
><br class="">
> I've never seen this before in other versions of Pd. Anyone else get this<br class="">
> behavior?<br class="">
><br class="">
> Matt<br class="">
</div></div>> _______________________________________________<br class="">
> <a href="mailto:Pd-list@lists.iem.at" class="">Pd-list@lists.iem.at</a> mailing list<br class="">
> UNSUBSCRIBE and account-management -> <a href="http://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank" class="">http://lists.puredata.info/listinfo/pd-list</a><br class="">
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>