It's not too fast

The bug report is usually the same three words, and they usually point at the wrong knob. It's too fast. Someone watches a step go by, can't follow what changed, and reports the obvious diagnosis: slow it down. I believed that report for about one lesson. The fix it asks for reaches for the clock — drop the playback speed, stretch every beat — but speed kept turning out not to be the knob that needed turning, and understanding why is most of what I know about pacing an animation.

Start with how long a step already lasts. A beat — one step of the animation — is thirty frames, and the canvas runs at thirty frames a second, so a beat is a full second on screen. A second is not too short to watch one thing happen. One pointer move, one comparison, one swap: a second is generous. So when a beat feels rushed, the second isn't too short. It's too full. You asked one second to carry three actions, and the eye tracking the first one misses the next two. Too fast is almost always density wearing a stopwatch.

The frame count is the wrong knob

Once you think the problem is speed, every fix you reach for is a clock. Surely a rushed beat needs more time — push it from thirty frames to sixty? Or the whole run drags, so shave every beat to twenty to tighten it up? Both moves treat the duration as the variable, and the duration was never the variable.

Stretching a crowded beat from thirty frames to sixty doesn't unfuse the three actions packed into it. It plays the same pile-up in slow motion — three things still landing on top of each other, now lingering twice as long while they do it. And shaving a clean beat down to save time takes a step that read fine and makes it unreadable, which is how too fast gets manufactured in the first place. The frame count is the wrong knob in both directions. You can turn it as far as you like and the beat is still doing too much.

So I split the beat

The lever that works is the number of beats, not the length of one. Take inserting a node at the head of a linked list. To the learner it's a single event: a new node shows up at the front. To the machine it's a short sequence of pointer writes, and the order of those writes is the entire lesson. Animate it as one beat — "now it's in the list" — and the new node, its next pointer, and the head pointer all snap into place in the same second. The one subtle thing, the order the writes have to happen in, is exactly the thing the single beat blurs.

So I split it into four. The new node gets allocated and floats above its slot, wired to nothing. Then its next pointer reaches out and grabs the old front of the list — one arrow, one second. Then, a full beat later, the head pointer swings off the old front and lands on the new node — one arrow, one second. Then the node drops into the row and settles. Four beats, thirty frames each, one write apiece.

Now the order is visible, because the learner watched it: next has to capture the old head before the head pointer moves. Do it the other way and you've orphaned the list — the head jumps to the new node first, and nothing remembers where the old front went. That order-dependence is the whole reason head insertion is worth animating, and in the fused one-beat version it's invisible. Splitting didn't just make the step legible. It made the step teach — the property was hiding inside the beat I'd crammed. The animation got longer by getting more steps, never by getting slower.

The number barely moves

So there's a number, and it almost never changes. A beat is thirty frames. The one exception is forty-five, reserved for a beat that genuinely is one big motion needing the extra half-second to track — a packet crossing the wire, a value flying between two far-apart cells, a dense thing revealed all at once. Never twenty. Never fifteen. The point of pinning it isn't that thirty is some perfect duration; it's that duration kept distracting me from the real lever, so I nailed it down and took it off the table. When a beat feels wrong now, I don't touch the clock. I count the actions in it. It's almost always more than one, and the fix is usually the same dull fix: find the fused beat, split it, leave the seconds alone.

Not every lesson lives up to this yet. Some of the older ones still fuse a couple of writes into a beat I haven't gone back to carve apart, and you can feel it — a step that slips by a hair too quick, the kind you want to rewind and replay at half speed to be sure of what moved. That itch is the diagnosis. It's never a setting that fixes it. It's the same decomposition, one more time.

It's the quiet frame, in time

There's a companion piece on this site about keeping most of the frame quiet — only one element loud at a time, the rest stepped back so your eye knows where to land. That post calls this habit its sibling and gets the relationship exactly right: quieting the frame is the discipline in space, and this is the same discipline in time. Don't crowd the frame; don't crowd the beat.

They're one bug seen from two sides — too much asking for attention at once — and they share one fix that has nothing to do with making the signal louder or the clock slower. Make the noise less. One thing loud per frame, one thing done per beat, and the learner follows the teaching without being told where to look or asked to keep up. The clock was never the problem.

See it: open linked lists and insert at the head. The new node's next pointer reaches the old front a full beat before the head pointer swings — two writes, two seconds, in the order that keeps the list from breaking.