← Back to Projects
Full-StackShipped

Count Coach

Dance practice tool: scrub a waveform, get BPM for that section, keep rehearsing.

I kept losing time hunting song sections and tempos, so I built the tool I wanted. Pick a region on the waveform, send it for tempo analysis, get numbers back without breaking rehearsal flow. Started in Colab, ended as a deployed Next.js app with Python on the backend. When the selection edges are wrong, the BPM looks wrong, and dancers blame the model. Sync mattered more than fancy DSP.

Engineering highlights

  • Waveform region select tied straight to analysis
  • Server-side tempo so the practice UI stays light
  • Colab prototype to a deployed app I still use
Date
2025-2026
Focus
Signal + Web
Build stage
Shipped personal practice tool
Disciplines
Signal Processing · Full-Stack UX
Source codeLive demo
signal-processingaudiofullstackdance
Demo
Full write-up below. The hero is the short version. This is the build story: what I designed, what broke, and why I made the calls I did.

Motivation

Why I started this

What pulled me in, and what I wanted to get better at.

Why I built it

Rehearsal time kept disappearing into 'where's that count' and 'what's the BPM of this section.'

What interested me

If the waveform selection and the analyzer disagree on boundaries, dancers think the tempo tool is broken.

What I wanted to learn

I moved a Colab prototype into a deployed Next.js app with Python analysis so I could use it in real practice.

System Overview

How the system fits together

Pick a region on a waveform, get tempo back, keep practicing. Thin web UI, analysis on the server.

01

Waveform UI

WaveSurfer selection bound to analysis requests.

02

Tempo analysis

Server-side Librosa-style BPM inference on the selected segment.

03

Practice loop

Overlay guidance for targeted repetition.

Data flow

Audio → region select → analysis API → BPM/metrics → UI overlay.

Engineering Breakdown

Broken down by discipline

Each block covers the goal, the design, what broke, what changed, and what shipped.

01Signal × Interface

Signal × Interface

Goal

Make tempo tools feel immediate during rehearsal.

Design

Waveform selection posts segment metadata; backend returns practice metrics; UI stays minimal.

Challenges

  • Selection boundaries must match what the analyzer hears.
  • Latency kills rehearsal flow if every scrub blocks.

Iterations

  • Colab prototype
  • Deployed app
  • Selection/analysis boundary fixes

Final implementation

Shipped practice tool used personally for sectioned rehearsal.

Practice loop

Region select → analysis → rehearsal guidance.

Key Design Decisions

Calls I actually made

What else was on the table, what I picked, and why it still made sense once the hardware was real.

01

Server-side tempo analysis

The problem

Where should Librosa-class work run?

Alternatives considered

  • Fully client-side
  • Server analysis

Tradeoffs

Client keeps data local but fights package weight; server keeps UX light.

Why I chose this

Server analysis with a thin Next.js client.

Evolution

How it got here

Bench bring-up, CAD fits, soldering, and the demos in between. Not just the final photo.

  1. v1

    Colab

    Analysis prototype.

    No media for this milestone yet.

  2. v2

    Deployed

    Waveform UI + API path.

    No media for this milestone yet.

Results & Validation

What held up

What worked in the end, what I can show for it, and where it's still limited.

Shipped practice tool

live demo + demo video

Used for personal dance rehearsal with waveform-linked BPM analysis.

Limitations

  • Niche UX; not a full studio suite.

Reflection

Looking back

What surprised me, what I'd redo, and questions I'm still chewing on.

What surprised me

  • Boundary sync bugs felt like 'wrong BPM' to users.

What I would redesign

  • Richer loop controls.

Future improvements

  • Movement-aware cues.

Questions that emerged

  • How little UI can a serious practice tool get away with?