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 <curtuller...@gmail.com> wrote: > 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 >
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
