Metronome

A metronome has one job. It makes a short sound at equal intervals, and it keeps doing so for as long as you ask. A wound spring and a swinging weight manage it without fuss. A web page, which can decode video and draw three-dimensional scenes, turns out to find it surprisingly hard.

The difficulty is not the sound. It is knowing when. A browser offers a page more than one sense of time, and they do not agree with each other closely enough for music. Which one a metronome trusts decides whether you can trust the metronome.

Two clocks that do not agree

The first clock is the one every script reaches for: a timer that says run this in half a second. It is convenient and it is loose. The timer’s callback runs on the page’s main thread, the same thread that lays out the page, handles input and collects garbage, so it runs when that thread is free and not before. The classic account of the problem describes callbacks arriving late by an unknown and variable number of milliseconds. For most of what a page does, nobody notices. For a pulse that is supposed to be even, there is nowhere for the error to hide.

It gets worse when the tab is not in front. To save battery, browsers deliberately slow the timers of hidden pages. One major browser enforces a minimum of one second between timer calls in an inactive tab. Another checks the timers of a hidden page once a second and, after the page has been hidden for more than five minutes and silent for thirty seconds, only once a minute. Pages that are making sound are treated more gently, but the rules differ between browsers and are theirs to change.

The second clock belongs to the audio system. The web audio standard defines its current time as the time of the sample frame that follows the last block of audio processed, counted in seconds from zero. It advances because samples were delivered to the sound hardware, not because a script got a turn. And the standard lets a sound be given a start time on that clock: the exact value is used, it says, without rounding to the nearest sample frame.

So there is a loose clock that can run code and a precise clock that cannot. The whole craft is in making them cooperate.

Looking ahead

The cooperation has a name, look-ahead scheduling. The loose timer wakes up often. Each time, it asks the audio clock what time it is, works out which clicks fall within a short window after that moment, and hands each of them to the audio system with its exact start time. Then it goes back to sleep. The timer no longer plays anything. It only makes appointments, and the audio clock keeps them.

Two numbers define the scheme, and the same account that named the problem suggests both. Its demonstration wakes every 25 ms and schedules everything due in the next 100 ms. Because the window is four times the interval, the passes overlap. The article shows one wake-up arriving fifty milliseconds late with the timing unharmed, because the click it would have scheduled had already been booked by an earlier pass.

The window has a cost. A click that has been handed over cannot be taken back, so a change of tempo cannot affect anything inside the window. The article puts it plainly: tempo changes take a tenth of a second to take effect. A careful metronome makes a virtue of that and applies a new tempo at the next beat that has not yet been scheduled, so the change lands on a beat boundary and never splits one.

There is a second, quieter trap. It is tempting to keep a running total: next click equals last click plus the interval. Every addition rounds a little, and the roundings accumulate. The safer habit is to compute each click from its index: start time plus the count of beats times the length of a beat. Then the ten-thousandth click is as exact as the first.

A hidden tab strains the scheme, because a timer that fires once a second cannot keep a 100 ms window full. A page can respond by moving its timer into a worker and by scheduling much further ahead while it is out of sight. What it cannot do is promise. If a browser holds the page up for longer than the window, the honest choices are to skip the clicks that were missed or to stop, and to say which happened.

What the clicks are counting

A tempo is a rate, usually written as beats per minute. Sixty means one beat a second and 120 means two. A marking such as a quarter note equal to 60 fixes which written note is the beat. The Italian words are looser. One widely copied list places Andante between 56 and 108 and Allegro between 120 and 156, with neighbors that overlap, and the same article notes that a modern Largo is slower than an Adagio while in the Baroque period it was faster. The words describe character. Only the number is a measurement.

What a beat contains depends on the meter. In simple meters the beat divides in two and then in four. In compound meters it divides in three, which is why its beat is always a dotted note: with 8 on the bottom, a dotted quarter worth three eighths. A bar of 6/8 therefore holds two beats, not six, and a metronome set to the eighth note and one set to the dotted quarter are counting the same music at numbers three times apart. It pays to know which one a score means.

Asymmetrical meters refuse to choose. Their bars are divided into unequal groups, some of two and some of three, and a signature such as 7/8 may be written out as 2+2+3 or 3+2+2 to say which. Here is one to reproduce. Set 7/8, type the grouping 2+2+3 and choose 132, counting eighths. Each eighth lasts 60 divided by 132, about 0.4545 seconds. The bar lasts seven of them, 3.18 s, and its three accents fall after 0, 0.909 and 1.818 seconds. The last group is half as long again as the others. That lopsided stride is the meter.

Swing bends the subdivision instead of the grouping. Jazz eighth notes are written evenly and played unevenly, shifting the proportion from 1:1 to, roughly, 2:1, so the first of each pair is about twice as long as the second. The word roughly matters. A metronome that offers one fixed swing has decided something players adjust by ear, which is why an adjustable ratio is more honest than a switch.

Polyrhythm sets two even layers against each other across the same span. A simple example is three evenly spaced notes against two, and four against three is another. The arithmetic underneath is a shared pulse, and its size is the lowest common multiple of the two counts. Three and two meet on a grid of six, four and three on a grid of twelve. Counting every pulse works for the simple cases and soon becomes unwieldy, since four against five already needs twenty of them. Seeing the common pulse drawn between the layers makes the pattern less mysterious.

Practising against a machine

Two practice devices follow naturally from a scheduler that knows bar numbers. A tempo trainer changes the tempo by a fixed step after a fixed number of bars. Start at 100, aim for 120, step by 5 every 2 bars, and the tempo passes through 105, 110 and 115 and arrives on bar 9. Whether creeping upward like this is the best way to build speed is a question for teachers, and nothing here settles it. What the arithmetic guarantees is only that the steps are small and arrive when promised.

The other device removes the click. Researchers who study timing use exactly this design: a person synchronizes with a metronome, the metronome stops, and the person carries on alone. In one published experiment with twenty adults at 50, 70 and 128 beats per minute, the hits became more disorganized relative to the absent pulse once it stopped, and at the faster tempos players tended to drift toward their own spontaneous tempo. Another study using the same design found musicians more precise than untrained controls at tapping. Silent bars put that test in your hands: play two bars with the click, two without, and hear whether you meet it when it returns.

When light and sound disagree

A screen wants to show the beat too, and it has its own delay. Sound scheduled for a given instant leaves the speaker a little later. Browsers can report an estimate of that output latency, the time between handing a buffer to the system and the device processing its first sample, and a display can subtract it. But it is an estimate, it depends on the platform and the hardware, and a page has no independent way to check it against what a wireless speaker or headphone really does. A slider that shifts the picture by ear is a small admission that the machine cannot know everything.

Light also carries a duty that sound does not. Accessibility guidance says nothing on a page should flash more than three times in any one second unless the flash stays below defined thresholds, because flashing content can trigger seizures. A metronome at 400 beats a minute with four clicks to the beat would flash nearly twenty-seven times a second. The answer is to stop flashing at such rates and show the beat with something that moves instead.

No scheduler can fix the other end of the chain. A page cannot tell whether the sound card’s own clock runs a hair fast, cannot verify the delay in a wireless speaker, and cannot hold a place in line when the operating system suspends it. What it can do is put every click on the best clock available, compute each one from first principles, and tell you when it could not keep its appointment.