DEV Community

praise
praise

Posted on AI-assisted

FASTKEYS: I Built a Play-Along Map for the Keyboardist Who Gets Sent a Song Five Minutes Before Rehearsal

Hacktoberfest Weekend Challenge: Build for a Friend Submission 🤝

What I Built
There is a very specific kind of panic keyboardists know.
Someone sends you a song you have never played before.
Rehearsal starts soon.
Now you are trying to answer several questions at once:

  • What key is this in?
  • What chords are moving underneath it?
  • What are the scale degrees?
  • What is the melody doing?
  • Where should my hands even start on the keyboard? I am a keyboardist too, and I built FASTKEYS for a keyboardist friend who runs into exactly this problem.

FASTKEYS turns an uploaded song into a synchronized Play-Along map.
You upload a recording, let FASTKEYS analyze it, then press Play.
As the original song plays, FASTKEYS follows along with:

  • the current chord
  • the scale degree
  • movable-do tonic solfa
  • detected lead-melody guidance
  • chord-tone keyboard guidance The important part is that this is not just a static transcription report. The song itself is the clock. If you seek to another part of the recording, the musical state moves with you.

If you transpose the song, the pitch names and chords change while the number system and relative solfa remain intact.
The goal is not to replace a musician's ear.
The goal is to give them somewhere useful to start when time is short.
I gave it to the friend I built it for
I asked my friend to try FASTKEYS without me coaching him through the product.
Before using it, I asked what he normally does when someone sends him an unfamiliar song shortly before rehearsal.
He said:
"Normally, I would just have to improvise and try to play along as the song goes."

After trying FASTKEYS, I asked whether it actually helped.
His response:
"It did. It gave me the chords and key. It was quite helpful."

He also gave me a realistic assessment of where the product is today:
"There's definitely still room for improvement, but right now FASTKEYS is useful, and it works."

And when I asked whether he would use it again in the same situation:
"I would."

He gave me permission to quote his feedback here.
That mattered to me more than getting a perfectly flattering review.

FASTKEYS did the thing I built it to do:
give a keyboardist somewhere useful to start.
Try it
https://fastkeys.onrender.com
Demo
Here is the full FASTKEYS workflow:

Direct video:
https://youtu.be/H6lN4HeOwOc
The demo shows the real product flow:
upload → analyze → play → follow the musical map → seek → resynchronize → transpose
Code
The source code is public here:

GitHub logo Techkeyy / FASTKEYS

Live AI-assisted song maps for keyboardists, with chords, scale degrees, tonic solfa, and keyboard guidance synchronized to playback

FASTKEYS

Turn an unfamiliar song into a live keyboardist play-along map.

Try FASTKEYS

FASTKEYS is for the moment a keyboardist gets sent an unfamiliar song shortly before rehearsal, service, or a performance. Upload the track and follow detected chords, scale degrees, movable-do tonic solfa, lead-melody guidance, and a keyboard map that stays synchronized with playback.

“I’ve never played this song. What do I play when rehearsal starts in five minutes?”

Why FASTKEYS

A keyboardist can know the song and still have no useful starting point when the first chord is minutes away. They normally need to work out the key, chord movement, number system, melody or solfa, and practical keyboard positions separately.

FASTKEYS gives them one place to start. The original recording remains the reference while the musical map follows it.

What FASTKEYS Does

  1. Upload a song. Choose a recording locally or start with one of the packaged samples.
  2. Build…






Repository:

https://github.com/Techkeyy/FASTKEYS

Live app:

https://fastkeys.onrender.com

The main stack is intentionally small:
  • Spotify Basic Pitch for open-source polyphonic note transcription
  • TensorFlow CPU for Basic Pitch inference
  • FastAPI + Python for the backend
  • FFmpeg / SoundFile for audio processing
  • chroma and harmonic analysis for key and chord mapping
  • plain HTML, CSS, and JavaScript for the Play-Along interface
  • Render for production deployment How I Built It The first version of FASTKEYS almost went in the wrong direction. I started with traditional digital signal processing. That included things like:
  • chroma features
  • harmonic analysis
  • key estimation
  • chord relationships
  • melody heuristics That gave me useful musical information, but it was not enough for the product I actually wanted. FASTKEYS needed a melody-aware timeline, not just a key and a list of chords. That is where Spotify Basic Pitch became the load-bearing AI component. Basic Pitch is Spotify's open-source automatic music transcription project, released under the Apache 2.0 license: https://github.com/spotify/basic-pitch FASTKEYS uses: basic-pitch==0.4.0

Basic Pitch turns the uploaded recording into timestamped note events.
FASTKEYS then combines those events with harmonic analysis and music-theory mapping to build the Play-Along experience.
The pipeline became:
Song
↓
Audio decoding
↓
Spotify Basic Pitch
↓
Timestamped note events
↓
Key + harmonic analysis
↓
Chord / degree / solfa / melody mapping
↓
Synchronized Play-Along

The 45-second bug
One of the biggest bugs showed up when I stopped testing only short clips.
Longer recordings seemed to stop producing useful results after around 45 seconds.
At first, that looked like an AI limitation.
It was not.
I eventually traced the problem to the audio preparation stage, where an FFmpeg command was still limiting decoded audio to 45 seconds.
Removing that limit exposed another challenge.
Running an entire multi-minute recording through transcription in one shot was not a good production strategy.
So I moved to chunked full-song inference.
FASTKEYS now processes longer recordings in approximately:
30-second Basic Pitch chunks
3-second overlap

Each chunk's local timestamps are mapped back onto the absolute song timeline.
Overlapping note events are reconciled so the result behaves like one continuous transcription.
I later tested the real production path with a recording over three minutes long.
The returned timeline continued through the full recording instead of stopping at the old 45-second boundary.
Making the music actually stay synchronized
Another problem was subtler.
At one point, the melody display looked responsive, but I had reduced detected notes into artificial 250 ms windows.
That meant the interface was inventing timing instead of respecting the timing produced by transcription.
I removed that shortcut.
The browser's real:
audio.currentTime

is now the authoritative playback clock.
The interface continually asks:
At this exact point in the song, what musical state should be visible?

That state includes:

  • chord
  • degree
  • solfa
  • melody guidance
  • keyboard guidance This is also why seeking works naturally. Jump somewhere else in the recording, and FASTKEYS immediately looks up the musical state for that timestamp. Transposition without losing musical meaning I also wanted musicians to move a song into another key without destroying the relationships they care about. So transposition changes pitch-based information. For example: Key: C → D Chord: C → D

while functional information remains:
Degree: 1 → 1
Solfa: d → d

That is much closer to how musicians think when someone says:
"Can we take this song up a whole step?"

Why Does Open Innovation Matter?
The open-source component is not decoration in FASTKEYS.
Without Spotify Basic Pitch, this would fundamentally be a different and weaker product.
Traditional DSP gave me useful information about harmony.
Basic Pitch gave FASTKEYS the timestamped note events needed to build a melody-aware musical timeline.
Because Basic Pitch is open source, I could run it inside my own backend, inspect its outputs, understand where its responsibility ended, and combine it with my own musical analysis instead of treating transcription as an opaque external API.
That became especially valuable when something went wrong.
When timing was incorrect, I could inspect the note events entering FASTKEYS.
When long songs failed, I could separate model behavior from problems in my own decoding and chunking pipeline.
The model output itself is not the product.
It is one open building block inside a system designed around a very specific musician's problem.
That is what I like most about open innovation.
Someone can open a capable piece of technology to the world, and another builder can understand it, adapt it, combine it with new ideas, and make something useful for a person the original creators may never have specifically designed for.
In this case, that person was a keyboardist trying to go from:
"I've never played this song."

to:
"Okay. I know where to start."

as quickly as possible.
My Agent Session
I used coding agents throughout the FASTKEYS build.
I tried to keep one rule consistent:
generated code was never treated as proof that the product worked.
The development process included:

  • inspecting failures before choosing fixes
  • testing musical invariants
  • testing timing and seeking behavior
  • testing long-song analysis
  • exercising the deployed API
  • performing production UAT
  • cleaning the public repository before submission One of the biggest architectural changes came after the early DSP-heavy version proved insufficient for the product I wanted. That led to Spotify Basic Pitch becoming the open-source transcription core, while FASTKEYS became the musical interpretation and synchronization layer around it. The most important lesson from the build was simple: implementation activity is not the same thing as the user getting the outcome you promised.

The question I kept returning to was:
Can a keyboardist press Play on the song they uploaded and have useful musical guidance follow that song?

That question drove the timing fixes, long-song fixes, Play-Along design, testing, and final production verification.

Prize Categories

Overall: Build for a Friend
FASTKEYS was built around a real problem faced by a keyboardist friend.
When he receives an unfamiliar song and does not have enough time to prepare, his normal approach is to improvise and try to follow the recording as it plays.
That shaped the whole product.
I deliberately avoided building a generic music-analysis dashboard.
FASTKEYS centers the Play-Along experience because that is what is useful at the exact moment the problem happens.
And after trying the product, the person I built it for told me:
"It gave me the chords and key. It was quite helpful."
That is the outcome I wanted.

Best Use of Render
Render hosts the live FASTKEYS application:
https://fastkeys.onrender.com
This is not just a static frontend deployment.
The production Render service runs the Python/FastAPI backend and the actual Spotify Basic Pitch inference pipeline used when someone uploads a song.
That means the most computationally important part of FASTKEYS, open-source music transcription, runs through the same deployed application judges can try themselves.
I also used the production environment to verify longer recordings through the real deployed path rather than treating successful local inference as sufficient proof.

Best Use of Backboard
I used Backboard R-CLI during development and verification to exercise FASTKEYS from outside the application's own test harness.
That included checking the deployed health and analysis paths and validating returned musical-analysis behavior.
Backboard gave me another boundary from which to interrogate the product instead of assuming that because internal tests passed, the externally visible application must also work.
That distinction mattered throughout FASTKEYS:
passing code is not automatically a working product.

What FASTKEYS Does Not Pretend to Do
Music transcription is difficult.
FASTKEYS currently works best when the recording has reasonably clear melody and harmony.
There are real limitations:

  • dense or highly polyphonic mixes can confuse lead-melody selection
  • chord identification can occasionally be imperfect
  • the keyboard visualization represents useful chord tones, not the exact voicing or fingering played by the original performer
  • multi-minute recordings require meaningful processing time
  • FASTKEYS is guidance, not a replacement for a musician's ear The goal is not magical perfect transcription. The goal is to reduce the time between hearing an unfamiliar song and understanding enough of its structure to begin playing.

If I had to summarize FASTKEYS in one sentence:
FASTKEYS turns "I've never played this song" into "I know where to start."
Hear it. See it. Play it.

Top comments (1)

Collapse
 
iszee23 profile image
praise •

let me know what you think guys