I believe I found the bug. I sent a pull request
https://github.com/ccrma/chuck/pull/151 with the fix and a lengthy
description. xcorr_fft is taking the FFT of the input, but the upstream
unit of the XCorr/AutoCorr UAnae is already required to be a UAna
https://github.com/ccrma/chuck/blob/main/src/core/uana_extract.cpp#L1210 (so,
it's already an FFT).
On Tue, Jul 21, 2020 at 1:07 AM Curtis Ullerich
As a preamble, I'll note that I posted a question on chuck-dev about AutoCorr/XCorr always crashing for me. This patch https://github.com/ccrma/chuck/pull/150 seems to fix that.
That said, I don't understand the results I get from AutoCorr. For periodic inputs, I expect to see periodicity in the output. For small FFT sample sizes, I see the expected peak at 0, and at large sample sizes I see a second peak at the end of the window. See example plots at 128 https://i.ibb.co/BBZXgBB/autocorr-128.png and 4096 https://i.ibb.co/Mn5fty5/autocorr-4096.png. That second peak is correlated with the window size, not the input frequency.
Thanks to Mario for his gnuplot wrapper https://github.com/mariobuoninfante/ChucK_various that captured those plots.
Here's the plotting code if anyone would like to repro: SinOsc s => FFT fft =^ AutoCorr c => blackhole; 4400 => s.freq; 128 => fft.size; 300::ms => now; c.upchuck(); Plot plot; "autocorrelation of 4400 hz, 128 samples" => plot.title; plot.plot(c.fvals()); 200::ms => now;
Should I be using AutoCorr differently? Am I looking at the power spectrum or something, and not the correlation vector like I think I am? My current understanding comes from reading uana_extract.cpp many times with references like this http://paulbourke.net/miscellaneous/correlate/.
Thanks, Curtis