Fellow ChucKists,<br><br><br>Below I'm pasting a slight edit of this example; <a href="http://chuck.cs.princeton.edu/doc/examples/analysis/win.ck">http://chuck.cs.princeton.edu/doc/examples/analysis/win.ck</a><br><br>Note that my change involved editing out the upchuck and replacing it with a transform on a array full of zero's. We'd expect that to result in silence. Instead it sound exactly like the original example. I believe this means that ,transform() is still looking to FFT's input instead of to the array fed to it. In Siebe's case that meant silence as he didn't chuck a UGen into his FFT.<br>
<br>I further tested this by feeding the input of FFT in Siebe's code with a Noise UGen and indeed in that case the printout dutifully supplies us with a train of numbers.<br><br>So, yes, that's a bug, probably a typo on .transform()'s code which seems to be taking the wrong array.<br>
<br>Yours,<br>Kas. <br><br>========demo code follows==============<br>// our patch<br>SinOsc g => FFT fft => blackhole;<br>// synthesis<br>IFFT ifft => dac;<br>// set srate<br>second / samp => float srate;<br>
<br>// set parameters<br>1024 => fft.size;<br>// window<br>Windowing.hamming(512) => fft.window;<br>Windowing.hamming(512) => ifft.window;<br><br>// use this to hold contents<br>complex s[fft.size()/2];<br>// divide<br>
int div;<br><br>float foo[fft.size()]; //note this is a array holding just zero's and will stay that way<br><br>// control loop<br>while( true )<br>{<br> // set freq<br> srate / fft.size() * div++ => g.freq;<br>
fft.size()/2 %=> div;<br> <br> // take fft<br> //fft.upchuck(); //commented out by Kas<br><br> fft.transform(foo); //added by Kas<br> <br> // get contents<br> fft.spectrum( s );<br>
// take ifft<br> ifft.transform( s );<br><br> // advance time<br> 256::samp => now;<br>}<br><br>