[sdiy] Tap tempo question

Brian Willoughby brianw at audiobanshee.com
Sat Feb 6 23:57:24 CET 2021

Good question.

There are multiple possible algorithms here, and optimizing one choice doesn't necessarily solve the same problems that another algorithm will handle.

The first consideration is to distinguish between Tempo matching by itself, versus Tempo matching with beat (phase) alignment. Weighted averaging of user tap rate does nothing to align the device beats to the user taps. I imagine that aligning the beats is almost a completely separate algorithm from matching tempo - unless you're using a phase-locked loop, which inherently includes phase matching at the same time as period matching.

You are correct that a pure delay can ignore alignment of beats entirely. A looper should be almost identical to a delay, because most loopers have the ability to stop the loop and then start it again on the beat. There's no guarantee that a looper recording starts on a beat, though, which probably makes it impossible to align beats. Anything that aligns tempo for a delay or looper will have to be designed to avoid glitches in the audio from sudden changes.

For an LFO, it should be possible to reset the LFO at the onset of Gate or when a Note On event is received. The Frequency of the LFO could be controlled independently of resetting the phase of the LFO waveform.

The most difficult challenge might be a sequencer or drum machine, where you probably want the beat to align to the taps, as well as having the tempo change to match the tap rate. In this case, you're probably less worried about saving processor cycles by using bit shift, and more likely to use a phase-locked loop instead. Something this complex will need a lot of parameters to control whether the sequencer jumps instantly to the new beat - which might be really distracting - or if it instead gradually shifts to align the beats to the tap at some maximum rate of change.

Note that computers can synchronize their local clocks with highly accurate clocks on the internet, but there are all manner of considerations. For one, time should never go backwards, or it will break certain kinds of software. That means a local clock that is fast will have to run slow until it lines up, because it can't jump backwards. Another consideration is that even though a local clock that is slow /could/ jump forward, it's probably better to avoid skipping more than one second at a time, instead running a little fast until the local clock catches up to the atomic clock, after which it can run at the correct speed. Time synchronization software keeps notes about the differences between rates, so it can stay in sync when not checking the time over the internet. These time algorithms are different from tempo, though, because they assume a steady local clock that is fairly accurate already versus a remote clock that is precise in rate and phase. Beat-matching a human is a different algorithm, but some of the same problems occur.

Brian Willoughby

p.s. I was just thinking about graphing the differences between a=0.5 b=0.5 and other optimized variations like a=0.75 b=0.25 ... I'm curious which would work better or worse than others. But no kind of averaging, optimal or not, will align beats.

On Feb 6, 2021, at 14:26, Mattias Rickardsson wrote:
> How would this kind of lowpass filtered tempo measurement be used in a real scenario?
> I was interested in how it performs if one would want it to follow and adapt to the beats tapped, and unless I misunderstood something, it results in something like the attached sketch (if it works).
> There we have a steady beat, and some tapping where the first tap comes too early (exaggerated in order to show the principle) and the other taps in proper timing. Tapped periods are measured, averaged by 50 % new + 50 % old, resulting in the beat positions at the bottom. When the low-pass filtered periods are stacked up, the beats don't align or adapt to the true beats. The initial timing error is gradually entering and never fading away.
> In a pure delay this would perhaps not matter, since there are no beats and no phases that need to align with each other, but in a sequencer or LFO or looper of some kind I guess some other mechanism is needed where the timings rather than the periods are analysed?
> /mr

More information about the Synth-diy mailing list