Calculate Beats per Minute (BPM) without using average

1k Views Asked by At

TL;DR: My question is not about programming. Calculating BPM (beats per minute) using average is not working well. Any other ideas?

I'm studying a programming language and decided to develop a simple "Tap Tempo" app. It basically get user mouse clicks and calculate the BPM (beats per minute).

However, it's taking too long to get closer to the real BPM and even so it's an approximation. The more samples (clicks) I have, the more it gets near the real BPM, but more samples means the user has to click too many times to discover the BPM.

I'm basically starting a timer when the user clicks the first time, then divide the number of beats (samples/clicks) per the elapsed time since the last click/beat.

Something like: BPM = beats_count / elapsed_time.

The number of beats increases at every click and elapsed_time is not being reset periodically, so it grows "forever". I tried to reset the timer, but it doesn't have the expected effect.

Do you have any clues on other strategy other than using the average of beats per time?

1

There are 1 best solutions below

1
On BEST ANSWER

I think I have a solution to part of your problem: subtract $1$ from your number of beats. Let me explain why:

Imagine I am a perfect metronome. I click at $120$ bpm, and I use your app.

Tap. The time starts. $t=0$. Tap, $t=0.5$sec. Tap, $t=1sec$.

If you're keeping track so far, one second has passed between the first and last clicks. I've tapped $3$ times, so by the formula $\text{bpm}=\frac{\text{clicks}}{\text{time}}$ I have a tempo of $\frac{3\text{ clicks}}{1\text{ sec}}=180\text{ bpm}$.

If I do another $4$ clicks, now there have been $3$ seconds since the beginning, and $7$ total taps. Calculated value: $140$ bpm. After $11$ clicks, there have been $5$ seconds since the start, so calculated value: $132$ bpm. Even if I tap for a full $30$ seconds, I've tapped $61$ times so the calculated value is $122$ bpm!

This is what's known as a Fencepost error; if I tap $n$ times, there have only been $n-1$ "gaps" in between my taps. If we take $n$ taps and divide by $n-1$ gaps, our estimate is always too high. But if we subtract $1$ from our taps, then suddenly the error is resolved; taps=gaps and all is right with the world.

See if that helps your count.

Edit: I see that while I was typing this answer, a conversation about this was happening in the comments. I'll leave this up in case it helps anyone.