# What's the delay for per tick for 60 bpm in a metronome

I'm developing a metronome software and I almost know nothing about music terminology. I'm following a metronome named Fine Metronome.

Lets say bpm is 60. And I have 4 ticks for one loop. One tick's duration must be 1000ms right? However in Fine metronome it's about 950ms. While I'm trying to add subunits (ex: 8/2, 12/3, 16/4) things became too complex. I need to use fractional numbers to get close to the ones in Fine Metronome (mine don't match them exactly). May it be related to the performance of my application? Because I get the number 950ms in my application while comparing.

What's the delay duration for one tick for 60 bpm?

• I don't think I understand your terminology well enough to provide an actual answer but I can say that it would sound correct to have 1000ms per tick for 60bpm, since 1000ms=1 sec and 60bpm = 1 beat per sec. I have no idea what your fractions are supposed to be for but those wouldn't be common time signatures if that's what you're thinking of and 12/3 is not even an actual time signature that would work within standard theory. Jan 5, 2018 at 14:52
• 1 minute = 60s, therefore 1s per beat. Divided by 4 = 250ms. The arithmetic really is that simple, for any bpm; you just happened to pick the simplest of all. 60/bpm/subdivision = ms per 'tick' Jan 5, 2018 at 14:52
• Thanks for the answers. So I'm having performance problems. Jan 5, 2018 at 15:01
• Not necessarily performance problems, maybe just synchronization problems. Read my post below. Jan 5, 2018 at 16:24
• This should be easy enough to test: play the metronome for one minute and count the ticks. If it's really off by 5%, you should get something like 63 ticks rather than 60. Jan 5, 2018 at 16:38

``````x bpm = x beats per minute = x/60 beats per second
``````

So the time between two beats (period in seconds) is:

``````p = 60/x
``````

You see that at 60 bpm:`p = 60/60 = 1 second`. At 120bpm, `p = 60/120 = 0.5 second`.

I also started programming a metronome (in GTK+ on Linux, but should work on Windows too if you install GTK+ separately), and things can get tricky in the timing. The problem is that you can't rely on the fact that your timers will wake you on the exact moment they should, unless you use a real-time operating system.

So there's a risk you play your tick slightly after the moment you wanted. The problem is that if you just measure the interval between two ticks, you miss the problem: errors add up at each tick, and after some tens of seconds, you are completely out of sync.

To avoid that, what I do is:

1. get current time at the moment the metronome is fired up
2. calculate the time of the next tick (tick 1)
3. set a timer to call me back when it's time to play tick 1, and "sleep" for that duration
4. when waking up, get the current time and play the tick sound for tick 1
5. calculate the time of tick 2, not based on current time but on the theoretical time tick 1 was supposed to be played
6. calculate the difference between the current time and the time tick 2 is supposed to be played, and "sleep" for that duration
7. etc.

This way if there's some lag at some point, you won't be completely out-of-sync at the end of the song. This allows for example to change the BPM while the ticks are played while still remaining reactive.

My code (in C) is at:

https://github.com/liberforce/metrognome

• I've already started to try what you told. I'll accept this as an answer when I finish it. Thanks for the detailed answer. Jan 5, 2018 at 17:45

At 60bpm., there is exactly one second between the end of the 1st tick, and the end of the second tick. So, allowing no time for the tick itself - which it must have, however small - there are 1000ms. If your metronome shows 950, it's going to be 5% out, which is not imperceivable to our sense of timing.

In your case, at 60bpm, the number of beats doesn't come into reckoning, but each click comes along 1 sec. after the last one - unless you mean 4 beats per click, when it's 250ms, very rapid.