← Back to Metronome StudioMetronome.pro

The Science of Zero-Drift Timing

What "zero-drift" really means

People say "zero drift" to mean: the metronome does not slowly wander off time while you practice. In real life, nothing is perfectly zero forever. But you can get timing that is so steady you won't hear it drift during a long practice session.

A metronome can fail in two main ways:

  1. Drift (slow error): Over minutes, the click slowly moves earlier or later compared to a stable reference.
  2. Jitter (shaky click): Each click is a tiny bit early or late. You hear it as "wobble" or "unevenness," especially at faster tempos.

A pro metronome minimizes both.

Why browsers make this hard

A web app runs inside a browser that is juggling lots of tasks:

  • drawing the screen
  • handling clicks and scrolling
  • loading images and data
  • running other tabs
  • saving power when your laptop is busy

If the metronome depends on "normal timers," the click timing can wobble when the browser is under load.

The key trick: schedule audio using the audio clock

Browsers have a special audio system called Web Audio. It has its own timeline called AudioContext.currentTime. This is like a stopwatch used just for sound.

Instead of saying: "play a click now, then wait, then play again," a pro approach is:

  • Look at the audio clock
  • Schedule future clicks slightly ahead of time
  • Let the audio system play them at the exact scheduled time

This is the main reason a good web metronome can feel "native app level."

The "Two Clocks" idea (simple version)

A stable metronome uses two "clocks," each doing a different job:

Clock A: The audio clock (accurate)

The audio engine plays sounds exactly when you tell it to.

Clock B: The scheduler tick (not perfectly accurate, but frequent)

  • A small loop runs many times per second (for example every 25 ms).
  • Each tick schedules the next batch of clicks into the audio engine.

Even if the scheduler tick is a little late once in a while, it doesn't matter much because the clicks were scheduled ahead.

This is why a good metronome stays steady even if you resize the window or your CPU spikes.

What "ahead of time" means

A typical approach is:

  • Schedule clicks 100–200 milliseconds ahead of time
  • Keep topping up the schedule

It's like keeping a small buffer of clicks ready to go.

Too small a buffer → you risk stutters.
Too big a buffer → changes (like tempo changes) can feel delayed.

A good metronome balances this.

How tempo changes stay clean

When you change BPM, a bad metronome may:

  • jump awkwardly
  • miss a click
  • "double click"

A good metronome applies tempo changes at a clean boundary — either at the next beat or at the next bar. Both are acceptable. The important part is consistency.

Why visuals can never be "perfect"

The screen (UI) updates on a different system than audio. Your display refreshes around 60–120 times per second. Audio timing is much tighter.

So the rule is:

  • Audio is the truth
  • Visuals follow audio as closely as practical

A realistic goal is: the flashing beat indicator feels in sync (usually within ~20 ms).

What you should expect from StudioMetronome.pro

A timing-first metronome should:

  • feel even and steady at slow and fast BPM
  • stay stable under CPU load
  • keep internal beat/bar counting correct even if you use training features like muted bars

If you want a deeper comparison, read: "Web Audio API vs. Standard Timers."