Yeah, pretty much. One can add further hacks to trade-off lag vs. stability and it might actually make sense to only FFT part of your buffer (depending on the maximum shift you want to allow) but .. yeah. Traditional zero-crossing sync does have the advantage that (when it works correctly) it's easy to keep the sync point at the particular position in screen, where as the correlation (as described above at least) is essentially "floating." Also the correlation is limited by FFT precision, so sometimes it can pick bogus estimates, but most of the time it works perfectly well.Robin from www.rs-met.com wrote:do i get that right that - from a high level perspective - the algorithm effectively computes an offset that maximizes the cross-correlation between the buffer shown in the current frame and the buffer shown in the previous frame?mystran wrote:Since the "auto-correlation" (well, technically cross-correlation between snapshots) algorithm is so ridiculously simple (and cheap), yet effective, I thought I'd share how I do it, since many simple scopes seem to have trouble tracking wave-forms with high resonance filtering, etc...
So here's the algorithm: [...]
...or stated differently: finds the lag, for which the cross-correlation between previous and current buffer is at its maximum and shifts the current buffer by that amount?
Well, the "quadratic on dB magnitude spectrum" is the part that I don't like. What I was thinking was to fit a Lagrange cubic or some such poly on the raw complex spectrum and just finding the maximum norm. This isn't audio rate stuff so "heavy" math isn't such a deal. If I draw everything using a general purpose anti-aliasing polygon rasterizer (and currently software-blending, though I could move that part to GPU), so a bit of iteration for peak finding won't make much of a difference. It's not high priority though, I want more "basic stuff" first.as for the "true" frequencies of spectral peaks - this might be helpful:
https://ccrma.stanford.edu/~jos/sasp/Op ... ctrum.html
Speaking of polygon rasterizers (the curves are just "stroke polygons" for paths), that's what I've spent the last few days at. I basically wrote two new rasterizers in the last two days, only to find out that neither of them comes close to matching my old 2006 algo (which approximates 16x16 samples). The second one isn't too bad actually (with exact 8x8 samples at least), but in the process of writing those, I did come up with several HUGE performance improvements to the old algorithm (to the point that my FFT is now a significant part of the drawing process, rather than some 1% detail).

