Toni MaxxToni Maxx

How I Would Build a Karaoke App Today

nostalgia pseudocode lean

  • Built with
  • JavaScript

Long ago I wrote karaoke software for Windows 3.1 and sold it to shops in Chiang Mai and Bangkok. I still like the problem. It is small, it is fun, and it is a good test of whether you keep things simple.

This note is not about how my old program worked. It is about how I would start a karaoke app today, if someone asked me. I wrote about the habit behind it in What the DOS Era Still Teaches Me. The habit is lean code: build the smallest thing that works.

What a karaoke app really is

Strip away the colours and the song lists. A karaoke app plays a song and shows the right word at the right moment. That is the whole job. Everything else sits on top of it.

So I would write the core first, in plain words.

LOAD song AND time-stamped lyrics
PLAY song
WHILE song IS playing
  now = AUDIO CLOCK position
  HIGHLIGHT the word whose time-stamp fits now
WEND

Six lines. If this works for one song, I have a karaoke app. If it does not, no menu will save it.

Rule one: the audio clock is the boss

The temptation is to start your own timer when the music starts and move the words with it. It works for a few seconds. Then it drifts.

A separate timer and the sound card do not agree on what a second is, and the two can differ by a tiny amount. Add a busy moment, a slow frame or a paused song, and the words are late. The singer notices very fast.

The fix is simple. Never keep a second clock. Ask the audio for its position, every time you draw, and show the word that belongs to that position. If the song stops, the words stop. If the song jumps, the words jump. They cannot disagree, because there is only one source of truth.

Try it below. Everything here is simulated, with no sound. Run the own timer, then switch to the audio clock and run it again.

Interactive · toy

A karaoke app shows the right word at the right moment. If a separate timer drives the words, it drifts from the music. If the audio clock drives them, they stay in step.

  • Own timer: starts with the song, then slowly drifts away from it.
  • Audio clock: ask the audio for its position every time you draw, and show the word for that position.
  • If the song pauses or jumps, the words pause or jump with it.
  • Get one song working end to end before lists, queues or effects.

The own timer in the toy runs only 8 percent slow, and you still see the words fall behind. Real drift is smaller per second, but a song is long.

Rule two: one song, end to end

I would resist the long list of features. No song library, no queue, no effects, no themes. First, one song that loads, plays and highlights every word on time.

Once that works, the next steps are easy to place. A song list is only many calls to the same "load song". A queue is a list of songs. Effects are decoration over the highlight.

Later, and only later

Two optional pieces come after the core is solid.

IF singer WANTS to record THEN
  RECORD microphone
  MIX voice WITH backing track
END IF
SCORE the take, LAST

Recording and mixing are real work, and scoring is a guessing game that people enjoy but should never block the first version. Score last, if at all.

The same loop as always

This is the same loop I use for client projects. Cut what is not needed today. Build, test and ship the one thing that matters. Add the rest from a list, after the first version is live.

If you have an app idea and you are not sure what the first small version should be, I am happy to help you find it. You can read how I work on the work page, see more toys on the widgets page, or browse all the notes.

Book a free consult

Where this comes from

The Windows 3.1 karaoke software and the lean-code habit are my own history. The pseudocode and the two rules are my own approach, and the widget is a simulation with original lines and no audio.