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;
}