DEV Community: NICK

28 milliseconds: turning drum notation into a schedule

NICK — Fri, 06 Nov 2026 02:15:00 +0000

28 milliseconds: turning drum notation into a schedule

Drum notation looks like it should be trivial to turn into sound. It is a grid of hits. Put a click on each one.

Then you try to encode a flam, and the whole model falls apart.

A flam is not two hits at the same time

On the page, a flam is two notes drawn almost on top of each other: a small grace note, then the main note. A naive reading says "play both", and if you do that literally you get a doubled click — which is not a flam, it is a mistake.

What a flam actually is: one hand plays a quiet grace note slightly before the main note, so close that the ear hears a single thicker attack. The spacing is tens of milliseconds, and the volume difference is most of the effect.

In the trainer I build, the spacing is 28 ms and the grace note plays at 0.10 of full amplitude against 0.18 for an ordinary note and 0.30 for an accented one. Those three numbers are the whole difference between a flam, a tap, and a flam accent. Get any of them wrong and the rudiment stops sounding like the rudiment.

That was the first lesson: the notation is not the schedule. The schedule is (time, hand, velocity), and the notation is a compressed description that has to be expanded first.

Encoding 40 rudiments as strings

The data for all 40 standard rudiments is a list of short strings:

{ n: 'Single Paradiddle', s: 'RLRRLRLL', g: 'Paradiddle' }
{ n: 'Flam Accent',       s: 'lR L R rL R L', g: 'Flam' }
{ n: 'Flam',              s: 'lR', g: 'Flam' }

Three rules do all the work:

A space separates steps. A step is a sixteenth note, so the grid is musical rather than absolute.
An uppercase letter is a main note; the letter is the hand (R or L).
A lowercase letter is a grace note, played 28 ms early and quiet.

Parsing is one line per character:

out.push({ right: lower === 'r', grace: ch === lower });

A single line covers a rudiment that would take a paragraph to describe in prose. And because the strings are readable, adding a rudiment is editing a string, not writing code.

The trade-off is that this encoding cannot express everything. It has no dynamics beyond accent/grace, no flams with double grace notes written differently from single ones, and no subdivision inside a step. For the standard 40 that is enough — and where it is not enough, I would rather have a second field than a more expressive string language.

Time is musical, not milliseconds

The tempo is in BPM, but the scheduler thinks in sixteenth notes:

function stepMs() { return 60000 / state.bpm / 4; }

Everything derived from tempo goes through that one function. Change the BPM and the whole sequence rescales, because no duration is hard-coded anywhere else. If any part of the code had stored "a step is 187.5 ms", the trainer would only work at one tempo.

This is the same reason the accent pattern is an array of step indices (acc: [0, 2, 4, 6]) rather than a per-note flag: the pattern has to survive a tempo change and a subdivision change without being rewritten.

Hearing which hand played

Both hands play the same voice — a triangle wave with a fast envelope — but at different frequencies: 1180 Hz for the right hand, 790 Hz for the left. Roughly a fifth apart, which is enough separation to hear two distinct hands and not so much that it sounds like two different instruments.

That is a small decision with a large effect on whether the tool teaches anything. If both hands sound identical, a student can hear that something played and cannot hear which hand played it, which is precisely the information a rudiment trainer exists to convey. Pitching the hands apart turns the audio into a check on the sticking: you can hear a wrong hand.

The envelope is four milliseconds of attack into an exponential decay. Without the fast attack the clicks smear; without the decay tail they sound like a test tone rather than a stroke.

The same index drives the screen

The player keeps a single index — which step is sounding — and the renderer highlights the matching span. There is no separate animation timeline to drift out of sync with the audio, because both read the same state.

This matters more than it sounds. Two timelines (one audio, one visual) always separate eventually, usually right when someone is watching closely. One source of truth cannot desynchronise from itself.

What this design costs

The audio is synthesised, not sampled from a real snare. That is a real limitation: a student practising to a sine click is learning the grid, not the sound. Recorded samples would sound better and would also multiply the page weight, the licensing questions, and the number of browsers that fail to decode them.

The encoding is deliberately narrow, and the tool is a reference rather than a teacher — it will play a rudiment at your tempo with the hands separated, and it will not tell you that your grip is collapsing.

Those are the boundaries I chose. The interesting part was not the audio code; it was discovering that most of the work sits between the notation and the schedule, in 28 milliseconds and three velocity levels.

The trainer described here runs at drumdesk.net/tools/rudiment-trainer — all 40 rudiments, 40–220 BPM, hands separated, no account.

A repair manual that has to know what is broken

NICK — Fri, 06 Nov 2026 02:07:28 +0000

A repair manual that has to know what is broken

Most "how to fix X" content is a list of steps. It assumes you already know what the fault is. That assumption is where most home repairs actually fail: someone watches a video about replacing a fill valve when the real problem is the flapper, and buys the wrong part.

So the design question I started from was not "how do I write instructions" but "how do I get from symptom to part without a technician". That changes the shape of everything.

The unit is a machine, not an article

Each guide opens with an animated diagram of the thing the user already owns — a tap, a toilet, a drain. The parts move because the mechanism is the explanation. A static drawing of a toilet tells you nothing about why it keeps running; a diagram where the flapper lifts and the fill valve opens shows you the failure before you read a word.

The diagram is not a video. Video is heavy, unsearchable, and impossible to pause on the exact frame that matters; it also cannot be re-rendered when the interface language changes. In the walkthrough the parts move as you go, so the explanation and the step are the same object rather than a picture sitting beside a paragraph.

Diagnosis is a tree, not a form

The diagnosis is two or three questions, and the answers are not a form submission — they are local state that narrows a decision tree. The tree is data rather than code, roughly:

{
  "id": "toilet-running",
  "question": "Does the water stop if you lift the float?",
  "yes": { "goto": "fill-valve" },
  "no":  { "goto": "flapper-seat" }
}

Two properties matter here. First, the tree has to be finite and small — if a symptom needs five questions, it is usually two different faults wearing one description, and the guide should be split. Second, every leaf must point at a part the user can actually see and name, or the diagnosis is useless in practice.

Everything runs client-side. There is no server deciding what to show, which means the whole thing works offline once loaded, and there is no analytics pipeline recording what broke in someone's bathroom.

The practice round is the part people skip

Before the walkthrough, there is a practice round: pick the right action without hints, wrong picks cost a mark. This came from watching how people actually use repair guides — they read the steps, nod, then open the thing and immediately lose track of which screw they were on.

The practice round is cheap to build (it is the same step data with the hints removed and a scoring wrapper) and it changes behaviour more than any amount of explanatory text. It is also the only part of the site that resembles a game, and I resisted making it more game-like on purpose: a repair guide that feels like a mobile game gets dismissed by the person who is standing in front of a leaking toilet at 11pm.

Four languages, not one language machine-translated

The site ships in English, Chinese, French and Spanish. The guides are written per language rather than translated by pipeline — the parts have different names in different markets, and a literal translation of "flapper" produces something no French hardware shop will recognise.

That is expensive, and it is the main reason the coverage is a set of common faults rather than an encyclopedia. The alternative — machine translation of 400 guides — would produce a site that ranks in four languages and helps in none.

What is not there

No account, no saved history, no "your garage" dashboard. The guides run in the browser and store nothing. That is a real limitation for anyone maintaining several properties, and it is the price of not having a login wall in front of a dripping tap.

The site is new, and it covers a small set of faults. It is not a substitute for a professional on gas, mains electrical, or anything structural — the site says so rather than hiding it in a footer.

If you want to see how the diagnosis and the animation behave together, the tap guide is the shortest path through all of it: supperman.net/faucet.

Three numbers that looked right and were wrong

NICK — Wed, 04 Nov 2026 07:54:47 +0000

Three numbers that looked right and were wrong

Every pronunciation guide says the same thing: /θ/ is a voiceless dental fricative, put your tongue between your teeth, don't voice it. That sentence is not wrong. It is also not checkable — you cannot look at it and decide whether the advice worked, and neither can a student.

So I built a reference where every number is measured instead of asserted. English phoneme symbols each get a page, a forced aligner runs over synthesised speech, and the page reports what the audio actually did: duration in milliseconds, pitch, harmonics-to-noise ratio, and for connected speech, the energy drop in decibels at a word boundary. /θ/, for instance, comes out at 77 ms mean across 12 measured tokens, with a 50–120 ms range and 13.0 dB mean HNR.

The interesting part of that project was not the pipeline. It was the three places where a correct-looking number turned out to be worse than no number at all.

The pipeline, briefly

Twelve English sentences, synthesised by a TTS engine in four American voices — two male, two female — 22.05 kHz mono at 64 kbps. Each sentence goes through MMS_FA for forced alignment, which gives a start and end timestamp per phone. From each aligned segment we compute duration, F0 and HNR. Everything is recomputed at build time from the audio; nothing is typed in by hand, and there is no database of "known" values to drift away from the files.

That last property matters more than it sounds. If the numbers live in a table that is edited by hand, the audio files and the table can drift apart, and nothing in the build tells you which one is stale. Deriving them from the audio every time removes that failure mode instead of monitoring it.

Number one: the /s/ centroid that follows the vowel

The easiest way to separate /s/ from /ʃ/ is brightness. /s/ concentrates energy higher. So compute the spectral centroid, sort, done.

Except the centroid moves with the next vowel. The same /s/ measured 8466 Hz in sun and 5293 Hz in sock. Once you sort six minimal pairs by centroid, shun at 5887 Hz comes out above sock at 5293 Hz — one crossing, and the neat story collapses.

The fix was to stop using a summary statistic that the following vowel can drag around. Instead the page reports the share of energy above 6 kHz. On that measure the lowest /s/ is 49%, the highest /ʃ/ is 44%, and across all six pairs there is no overlap at all. The same six pairs, the same audio, two metrics — one produces a ranking with a hole in it, the other produces a clean separation.

Duration told a similar story: across all six pairs /ʃ/ is longer, with /s/ running 40–60 ms and /ʃ/ running 70–91 ms. That is a real cue, but it is not the one people teach first.

The point is not "use spectral share". It is that a metric which is easy to compute and easy to explain can still be the wrong metric, and you only find out by checking whether the ranking holds across every pair rather than the pair you happened to plot.

Number two: the 2 ms difference we refused to print

Elision guides say that -ing becomes -in' in casual speech. Fine. So measure it: 12 sentences, 6 pairs, full spelling against the apostrophe version, same four voices.

Target word length came out at 334 ms mean, range 262–383 ms. And the pair that motivated the whole page — something against somethin' — measured 383 ms against 381 ms. Two milliseconds.

Printing that would be worse than printing nothing. A reader sees "383 vs 381" and concludes there is no difference, which is false: the difference is in the transcription, not in the duration. So that cell is empty on the page, with a note explaining exactly this, and the measurement is still in the build output for anyone who wants it.

There was a second trap in the same experiment. When the target word sat at the end of the sentence, the aligner stretched its end time to the end of the clip — fishin' came out at 1252 ms, which is nonsense. Target words now sit mid-sentence. This is the kind of bug that never announces itself: the number is present, plausible-looking, and off by a factor of four.

You can see how both decisions are rendered on the elision page — the empty cells are marked as empty rather than filled with something adjacent.

Number three: formants on audio that cannot support them

Weak forms are the most obviously measurable thing in connected speech: a function word gets compressed, so its duration ratio against its strong form should drop. Measured ratios came out at 0.3–0.5, often 60–80 ms — which is three or four analysis frames at a 20 ms window. Tight, but usable.

Then I tried to add formants, because "the vowel centralises towards schwa" is the standard explanation and F1/F2 would show it. On 16 kHz conversational audio, twelve vowels measured in Praat, five came out clearly wrong: tell returned F1 1031 Hz and F2 1235 Hz where roughly 600 and 1800 Hz were expected. At a 20 ms frame there is not enough pitch information for a reliable formant estimate.

The honest conclusion was to drop the formant column for that audio rather than ship numbers that would look authoritative and be wrong a third of the time. The lesson generalises: when the recording cannot support a measurement, no amount of post-processing makes it support one. Changing the analysis method does not add information that was never captured.

What "measured" means for connected speech

Linking is where most guides switch from description to judgement: "these words are linked". That is not falsifiable either. What is measurable is the energy dip at the join.

For every word boundary we take the energy envelope in 5 ms windows with 2.5 ms steps, find the quietest point within ±60 ms of the boundary, and subtract it from the median energy inside the window. The result is a number in dB. A few from the linking page: -2.4 dB, -1.8 dB, -0.5 dB, and one at +0.7 dB where the "join" is louder than the surroundings — sentence medians run from 12.6 to 22.0 dB.

That single change — from a label to a measurement — makes the claim checkable. You can disagree with the threshold, but you can see what the audio did.

The part that is boring and decides whether it works

Every figure is recomputed on each build. Where a value cannot be measured, the cell stays empty and the page says why. The interface language and the target language are separate choices, so an English speaker reading about Spanish /θ/ and a Chinese speaker reading about it get different pages, not a machine translation of one page.

None of that is novel engineering. It is the ordinary discipline of not printing a number you cannot defend — which, for a reference site, turns out to be the whole product.

If you want to see the metric comparison that started this, the /s/ and /ʃ/ page shows both the centroid and the above-6 kHz share side by side, including the pair where the centroid ranks them the wrong way round.

All figures above are from the current build of Phoneme·Trick, a free pronunciation reference. Audio is synthesised, not recorded from learners — which limits what the numbers can claim, and the site says so wherever the numbers are documented.

Three conversions that quietly break in production: cron, SQL dialects, and time zones

NICK — Wed, 04 Nov 2026 00:57:54 +0000

Three conversions that quietly break in production: cron, SQL dialects, and time zones

Every team has a small set of conversions that nobody owns. They get pasted into a scratch file, run once, and forgotten — until the one month a year when they are wrong.

I collected three of them into browser tools because I kept re-deriving them, and each one has a failure mode that only shows up at a specific time of year or on a specific engine. The failure modes are more interesting than the tools, so here they are.

1. Cron: the expression is right and the job still doesn't run

0 2 * * * means "2am every day". In a timezone with daylight saving, it means "2am every day except the day the clocks jump", because 02:00 does not exist on that date. Many schedulers skip the run entirely; some run it twice on the way back.

The mistake is treating a cron expression as a time. It is a local calendar rule, and local calendars have holes and duplicates:

Spring forward: 02:00–03:00 never happens. A job pinned to 02:30 has no valid instant.
Fall back: 01:00–02:00 happens twice. A job pinned to 01:30 has two valid instants.

So a useful cron explainer has to do two things beyond translation:

Resolve the expression against a real timezone, not against UTC arithmetic. "Next 5 runs" is only useful in the timezone the operator lives in, with DST rules applied to each occurrence independently.
Show the hole. If the next occurrence lands in a spring-forward gap, say so, rather than silently skipping to the day after — that is the difference between a bug report and a mystery.

The other thing worth surfacing is the count of runs: */15 in the minute field is 96 runs a day, and 0 0 1 * * is 12 a year. Half of "why is our queue flooded" tickets are somebody reading a cron as "every hour".

I built a cron explainer that prints the next runs in your own zone with DST applied, and flags the DST edge case explicitly: Cron Expression Explainer.

2. SQL dialects: silent disagreement is worse than a syntax error

Every ORM promises dialect independence, and every project with more than one database eventually hits the seams. The tricky ones are not the syntax errors — those you find in CI. The tricky ones are the constructs that are valid in both dialects and mean different things:

Construct	MySQL	PostgreSQL	SQLite
`"double quotes"`	string literal (unless `ANSI_QUOTES`)	identifier	identifier
`LIMIT 10, 20`	offset 10, count 20	syntax error	offset-comma supported
`TRUE` / `FALSE`	tinyint 1/0	real boolean	1/0 stored as integer
`INSERT ... ON DUPLICATE KEY`	native upsert	needs `ON CONFLICT`	`ON CONFLICT` or `INSERT OR REPLACE`
Implicit string→number cast	permissive	strict, errors	permissive

The "double quotes" row is the one that gets people. A query written against MySQL that quotes a string with double quotes will, after a migration, be interpreted as an identifier — and depending on the driver's quoting behaviour, it can fail loudly or return something plausible. Plausible is the dangerous outcome.

That is why a converter that guesses is worse than one that refuses. When I built the SQL formatter/dialect converter, the rule I settled on was: translate what is provably equivalent, list every change made, and flag anything that cannot be translated safely instead of approximating it. A converter that hands you SQL and says "3 constructs were rewritten, 1 could not be translated" is usable in a migration review. One that silently produces something that runs is a trap.

3. Time zones: offsets are not time zones

The classic bug: someone stores a timestamp with an offset, or worse, converts to a fixed offset once and stores that. Then a date six months later is off by an hour, because the offset was a property of one moment, not of the zone.

Two facts that make this concrete:

An offset is a snapshot; a zone is a rule set. 2026-03-29T01:30+01:00 tells you one instant. Europe/London tells you how to interpret every wall-clock time in that zone — differently before and after the transition.
Wall-clock times can be missing or duplicated. Same holes as cron. If a user types 2026-03-29 01:30 in London, that time does not exist; a naive parser will happily produce an instant an hour off, and the confirmation email will say the wrong thing.

The practical rules I keep re-learning:

Store UTC instants plus the IANA zone name if you need the local wall clock later. Never store a derived offset as the source of truth.
When parsing user input, treat "this time does not exist" and "this time is ambiguous" as validation errors you must decide about — not as parser edge cases. Pick a policy (shift forward / pick the first occurrence / reject), and put it in the code where a reviewer can see it.
When displaying, convert at the edge. Formatting in the database is where zone rules go to die.

The time zone converter exists because I wanted to see the failure rather than have it explained: enter a wall-clock time and a zone, and if that time falls in a gap or a duplicate, it says so instead of picking silently.

Why these live in the browser

All three are pure functions: text in, text out. There is no reason for a server to be involved, and a real cost if one is — anything pasted into a "quick converter" is often a production fragment, a customer list, or a connection string.

So the constraint I set was: the input never leaves the page. No upload, no account, no analytics on the content. It simplifies the security story to nothing and removes the temptation to log request bodies "for debugging".

The trade-offs are honest ones: no server means all the parsing happens in JavaScript on the user's machine, so heavy inputs are limited by their browser, and there is no API for scripting. For a pasted cron expression or a 200-line SQL file, that is the right trade.

The other two conversions in the same family — JSON/YAML/TOML with errors pinned to line and column, and IP subnet with IPv6 — follow the same rule: show the failure precisely, do not paper over it.

If you have a fourth conversion in this category — one where being silently plausible is worse than erroring — I would like to hear which one, because that is the list I am building next.

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

DEV Community: NICK

28 milliseconds: turning drum notation into a schedule

28 milliseconds: turning drum notation into a schedule

A flam is not two hits at the same time

Encoding 40 rudiments as strings

Time is musical, not milliseconds

Hearing which hand played

The same index drives the screen

What this design costs

A repair manual that has to know what is broken

A repair manual that has to know what is broken

The unit is a machine, not an article

Diagnosis is a tree, not a form

The practice round is the part people skip

Four languages, not one language machine-translated

What is not there

Three numbers that looked right and were wrong

Three numbers that looked right and were wrong

The pipeline, briefly

Number one: the /s/ centroid that follows the vowel

Number two: the 2 ms difference we refused to print

Number three: formants on audio that cannot support them

What "measured" means for connected speech

The part that is boring and decides whether it works

Three conversions that quietly break in production: cron, SQL dialects, and time zones

Three conversions that quietly break in production: cron, SQL dialects, and time zones

1. Cron: the expression is right and the job still doesn't run

2. SQL dialects: silent disagreement is worse than a syntax error

3. Time zones: offsets are not time zones

Why these live in the browser

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

The three ways setInterval loses

Two clocks, and only one of them can be trusted

The scheduler

Making a click that doesn't sound like a click

The visual can lag. It can't disagree.

One more thing: the context starts suspended

Why bother with the browser at all

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

45 free browser tools that answer one question well

What "one question well" means in practice

Why everything stays client-side

Who it is for

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

The constraint I set myself

What's in there

What I would tell someone starting the same thing

The honest part

The three ways `setInterval` loses