DEV Community: NICK

setInterval can't keep time: building a metronome that doesn't drift

NICK — Mon, 26 Oct 2026 00:46:29 +0000

Open a metronome built with setInterval, set it to 120 BPM, leave it running for two minutes, then play a click track next to it. They will not still be together.

This is not a bug in the metronome. It is setInterval doing exactly what it promises, which is "run this callback roughly every N milliseconds, if you can." A metronome needs something much stronger: "produce a sound at this exact point in time, no matter what else the page is doing."

I ran into this when building DrumDesk, a couple of browser-based practice tools. The fix is older than most of the frameworks I use, and it is worth writing down because the wrong version sounds almost right — which is worse than sounding obviously broken.

The three ways `setInterval` loses

1. The main thread owns it. setInterval callbacks go into the same queue as your event handlers, layout, garbage collection, and third-party scripts. If the browser spends 180ms doing layout, your click is 180ms late. It does not get rescheduled to catch up — it just arrives late, and then the next one arrives on the new, slightly wrong schedule.

2. Background tabs get throttled. Browsers clamp timers in inactive tabs — historically to 1 second, and still to at least a few hundred milliseconds in most cases. A user who switches to their email to look up a tempo marking comes back to a metronome that is no longer a metronome.

3. Errors accumulate. setInterval(fn, 500) does not mean "call fn every 500ms of real time." It means "wait at least 500ms between calls." Every delay is added to the timeline permanently. Small delays are the norm, so the drift is monotonic — it only ever goes one way.

The third one is what makes it insidious. A metronome that is 8ms fast sounds fine. A metronome that gets 8ms slower every bar is a different instrument after a minute.

Two clocks, and only one of them can be trusted

The thing that changed my approach: Web Audio has its own clock.

AudioContext.currentTime is driven by the audio hardware, not by the main thread. It advances in real time even when your JavaScript is blocked, because the audio pipeline runs on a separate real-time-priority thread. If the main thread stalls for 200ms, currentTime keeps moving and the sounds you already scheduled still fire exactly when you scheduled them.

So the architecture becomes:

A slow, sloppy timer that periodically wakes up and asks "do I need to schedule more sounds yet?" It is allowed to be late. Nobody hears it.
The audio clock that decides exactly when each sound plays. It is never late.

This is the pattern Chris Wilson described as "A Tale of Two Clocks" in 2013, and it is still the answer.

The scheduler

The trick is a lookahead queue. Every 25ms, look 150ms into the future and schedule everything that falls inside that window. Then go back to sleep.

var nextTime = ctx.currentTime + 0.05;   // when the next note should sound
var LOOKAHEAD = 0.15;                    // seconds of future to pre-schedule
var INTERVAL = 25;                       // ms between wake-ups

function schedule() {
  while (nextTime < ctx.currentTime + LOOKAHEAD) {
    click(nextTime, /* isRightHand */ true, 0.35, false);
    nextTime += stepSeconds();           // one subdivision
  }
  timer = setTimeout(schedule, INTERVAL);
}

Two numbers, two different jobs:

INTERVAL = 25 can drift, jitter, or arrive 60ms late. It does not matter, because its only job is to keep the buffer full.
LOOKAHEAD = 0.15 is the safety margin. Any main-thread stall shorter than 150ms is completely absorbed. A stall longer than that will produce a gap — but that is a genuinely broken page, not a busy one.

The while loop is the important part. If the timer fires late, the loop runs several times in one go and catches up. Compare that to setInterval, which can only ever fire once per tick and therefore falls further behind forever.

Making a click that doesn't sound like a click

Scheduling a sample-accurate start time is half of it. The other half is making the sound not be a pop.

A bare oscillator started and stopped abruptly produces a discontinuity in the waveform, which you hear as a click — an ugly one, distinct from the click you actually wanted. The fix is a fast envelope:

function click(at, isRight, vol, long) {
  var dur = long ? 0.16 : 0.07;
  var osc = ctx.createOscillator();
  var g = ctx.createGain();

  osc.type = 'triangle';
  osc.frequency.setValueAtTime(isRight ? 1180 : 790, at);

  g.gain.setValueAtTime(0.0001, at);                       // start near zero
  g.gain.exponentialRampToValueAtTime(vol, at + 0.004);    // 4ms attack
  g.gain.exponentialRampToValueAtTime(0.0001, at + dur);   // decay to silence

  osc.connect(g);
  g.connect(ctx.destination);
  osc.start(at);
  osc.stop(at + dur + 0.01);                               // small tail
}

Three details in there are worth stealing:

It starts at 0.0001, not 0. exponentialRampToValueAtTime cannot ramp to or from zero — a zero target throws, and a zero start makes the ramp mathematically meaningless. 0.0001 is the usual idiom. You will find this out the hard way otherwise.

The oscillator is stopped slightly after the envelope ends. dur + 0.01 gives the gain node time to finish ramping before the source dies. Without it you can get a truncated tail.

Right and left hand get different pitches. 1180 Hz against 790 Hz is roughly seven semitones apart — far enough to hear which hand is which, close enough that it still reads as one instrument. For rudiment practice this matters more than any visual notation: you hear a wrong sticking before you see it.

The visual can lag. It can't disagree.

Once the audio is sample-accurate, the UI becomes the problem. If you highlight the current beat inside the scheduler loop, the highlight happens ~150ms before the sound — because you scheduled it, you did not play it.

The fix is to keep the visual on a separate timer that fires when the note is actually due:

setTimeout(function () {
  renderSticking(i);
}, Math.max(0, (at - ctx.currentTime) * 1000));

A visual that is 20ms behind the audio is invisible. A visual that is 150ms ahead makes the whole tool feel broken, even though the audio is perfect. Humans forgive latency; they do not forgive contradiction.

One more thing: the context starts suspended

Browsers will not let you make noise before a user gesture. new AudioContext() creates a context in suspended state, and every start() on a suspended context is silently dropped.

if (ctx.state === 'suspended') { ctx.resume(); }

Call it on every play action rather than once at load — the context can be suspended again after a tab has been backgrounded, and "the metronome works until I switch tabs" is a confusing bug report to receive.

Why bother with the browser at all

Because the alternative is asking someone to install an app to hear a click.

The whole premise of these tools is that a drummer sits down for ten minutes, wants a metronome and a subdivision grid, and should not have to create an account, download 40MB, or watch a splash screen first. Browser audio was "not good enough" for long enough that the assumption stuck around. With a lookahead scheduler it is sample-accurate, and the latency budget belongs to the audio thread rather than to whatever else the page is doing.

The tuner next to it uses the same clock for a different job: f = base × (A4 / 440) × 2^(cents / 1200), which is boring, correct, and instantly verifiable against a reference tone.

If you want to hear the result rather than read about it, the rudiment trainer is here — 40 rudiments, left and right hand at different pitches, 40–220 BPM, subdivisions, and a random mode. No account, no install, nothing stored. It exists because the setInterval version I wrote first was, to put it kindly, not a metronome.

The 20-second rule: when a browser tool beats an app

NICK — Thu, 22 Oct 2026 03:27:06 +0000

There is a threshold I stopped arguing with: if a job takes less than twenty seconds, I refuse to install anything for it.

Not because installers are evil. Because the overhead is invisible until you count it. An installer is a download, a EULA, a restart, an update notification six weeks later, and one more icon competing for your attention. For a task I do twice a month, the tax is bigger than the task.

What actually crosses the line

The tasks below are all under ten seconds of work once the page is open, which is why they live in a browser tab instead of a menu:

a percentage change between two numbers I read somewhere
a timestamp someone pasted in a Slack thread
a subnet mask I want to sanity-check before touching a config
the length of a string I just typed into a validation rule
a currency or unit conversion, usually while reading documentation

None of these deserve an app. All of them are one search away from a site that wants my email.

The rule, stated properly

If the tool does not need my data, does not need to run in the background, and does not need a history, it should not be installed.

That last clause is the interesting one. History is the only real reason to install a desktop tool: a timestamp converter that remembers my last ten inputs is genuinely better than one that does not. Everything without state should be a page.

Where this gets uncomfortable

Browser tools have a bad reputation because most of them are pageviews with a text box. You can usually tell within five seconds: if the page asks you to sign up before it shows a result, it is not a tool, it is a funnel. If it works with JavaScript disabled, it is probably a real calculator.

The collection I keep on a pinned tab is 1024Toolkit — 45 single-purpose pages (converters, calculators, encoders, generators), no account, nothing to install. I pin it because the alternative is a search results page full of ads pretending to be tools.

The part I did not expect

Treating small jobs as browser jobs changed what I install, not how much I work. My machine has fewer programs on it than it did a year ago, and I have not missed one. The twenty-second rule quietly deleted a whole category of software from my life.

If you want to test the rule, pick the smallest thing you did today — the one you would be embarrassed to install an app for — and see whether a page does it. It usually does.

45 free browser tools that answer one question well

NICK — Wed, 21 Oct 2026 13:04:26 +0000

Most calculator sites have a business model that works against the answer. You get four fields and a paywall, or a page that needs an account before it shows a number, or a result that arrives wrapped in three ad blocks. The question underneath never changed: how much, how many, how long?

1024Toolkit is my attempt at the opposite. It is a free collection of 45 browser tools for finance, health, engineering and development. Each tool answers one question well and runs entirely in your browser — no sign-up, no account, nothing uploaded, four languages.

What "one question well" means in practice

Take compound interest. The question is not "can you model monthly contributions with variable rates and a tax wrapper?" It is: what does £150 a month become at 6% over fifteen years? One number, one curve, two fields. Anything more belongs in a spreadsheet.

The same discipline shaped the rest:

Position sizing — what should this trade be, given my account and my risk per trade?
BMI — one weight, one height, one classification.
Concrete volume — how many bags for 2.4 m³, and how much does that cost?
Cron expressions — what does 0 3 * * 1 actually run, and when is the next run?
Subnet maths — what does a /27 leave me with?

Why everything stays client-side

Every calculation runs in JavaScript in your own tab. There is no server to send numbers to, which means there is also no database to breach and no "free tier" to upgrade from. It also means the tools keep working when a train tunnel eats your signal — as long as the page is open, the maths works.

Who it is for

Honestly: anyone who re-googles the same conversion more than twice a week. Developers get cron, subnet and timestamp tools; investors get compound interest and position sizing; DIY gets concrete and paint coverage; the gym gets BMI and plate math.

The full set lives at 1024toolkit.com — one tab, 45 answers, no account.

45 tiny tools, zero hassle: what I learned shipping one-page utilities

NICK — Wed, 14 Oct 2026 15:36:41 +0000

Every few weeks I hit the same small wall.

I need to know what 0 3 * * 1 actually means. Or how many bags of concrete 2.4 m³ is. Or what
£150 a month turns into at 6% over fifteen years. Nothing hard — just a question that should take
ten seconds to answer.

And every time, the same routine: land on a site that wants an account, or pushes my numbers to a
server, or is more ad than page.

So I started collecting the answers I kept needing as single static pages. That collection is now
45 tools, and it lives here: https://1024toolkit.com

The constraint I set myself

One rule shaped everything else: a tool must answer one question, and it must work without me.

That meant:

No account. Nothing to sign up for, nothing to remember, nothing to reset.
Nothing you type is stored. Whatever you enter stays in the tab. (A couple of tools need live data — the stock lookup, for instance — and fetch it through a thin proxy. Nothing you type is saved there either.)
One question per page. If a tool needs a manual, it is the wrong tool.

The discipline of "one question per page" sounds limiting. In practice it is the opposite — it
makes every addition obvious. Either the tool collapses into a single input and a single result,
or it does not belong.

What's in there

45 tools, in four loose clusters plus a long tail of everyday ones:

Finance — compound interest, savings-rate, discount, options payoff, position sizing
Engineering — concrete volume, cut lists, triangle geometry, great-circle distance
Health — BMI, BMR, TDEE, heart-rate zones, A1C
Developer utilities — cron, regex, timestamps, time zones, subnets, SQL formatting, mock data

The developer ones are the reason I started. I got tired of opening a heavyweight site to decode a
cron string I was staring at anyway.

The whole site is also available in four languages (English, German, Japanese and Simplified
Chinese), which turned out to be far less work than expected once the tools were small enough.

What I would tell someone starting the same thing

1. Ship the boring version first. A page with an input, a label and a result is a legitimate
tool. I have talked myself out of more tools by planning a "proper" version than by any other means.

2. Name the tool the way people search for it. "Cron expression parser" beats "TimeKit" every
single time. The name is the feature.

3. Almost no backend is a feature, not a shortcut. Every server you do not run is a data breach
you cannot have, a bill you do not pay, and a page that keeps working when something upstream is
down. The handful of endpoints I do run exist only to keep an API key off the client — never to hold
your data.

The honest part

These are small tools. None of them is clever. The value is that they are there, they load
instantly, and they never ask for anything.

If you use one and it is missing an input you need, or the answer is wrong, I would genuinely like
to know — that is the most useful feedback I can get.

https://1024toolkit.com