Fellow ChucKists, Below I'm pasting a slight edit of this example; http://chuck.cs.princeton.edu/doc/examples/analysis/win.ck 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. 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. So, yes, that's a bug, probably a typo on .transform()'s code which seems to be taking the wrong array. Yours, Kas. ========demo code follows============== // our patch SinOsc g => FFT fft => blackhole; // synthesis IFFT ifft => dac; // set srate second / samp => float srate; // set parameters 1024 => fft.size; // window Windowing.hamming(512) => fft.window; Windowing.hamming(512) => ifft.window; // use this to hold contents complex s[fft.size()/2]; // divide int div; float foo[fft.size()]; //note this is a array holding just zero's and will stay that way // control loop while( true ) { // set freq srate / fft.size() * div++ => g.freq; fft.size()/2 %=> div; // take fft //fft.upchuck(); //commented out by Kas fft.transform(foo); //added by Kas // get contents fft.spectrum( s ); // take ifft ifft.transform( s ); // advance time 256::samp => now; }