codeforchord

• 

  chord detection

• 

  sheet generator page

• 

  rearrangment

• 

  sheet generated

• 

  record page

• 

  main page

• 

  login page - enables MongoDB for personal use

Inspiration

When we play in band, pianists are usually the ones handling all the heavy lifting—rearranging parts, changing keys, and writing out sheets for everyone else. We wanted to give non-pianists the same power: anyone in the group should be able to transpose, adapt, and turn recordings into notation without depending on one person or years of keyboard training.

What it does

CodeForChord is an ML-assisted music assistant that:

How we built it

Challenges we ran into

1. Data: MusicXML + audio
   We needed a pipeline to collect, clean, and align MusicXML (and audio where possible) so the model could learn from how music is normally written, not only from raw detector output.

2. “Too accurate” vs. readable scores
   Early builds over-dissected timing—every micro-deviation became notation. Real charts are simplified and patterned. We leaned on quantization, merging, and rhythm correction so the program respects standard written music, not literal milliseconds.

3. Cloud storage vs. user burden vs. privacy
   We avoided forcing local file and disk management on users, while keeping trust in where recordings and sheets live. Cloud storage with an LRU cache policy bounds cost and stale data; auth and clear data practices support privacy without dumping housekeeping on the band.

Accomplishments that we're proud of

• Tied to our inspiration: We turned “only the pianist can rearrange and chart” into “anyone can transpose, adapt, and generate sheets” through the product—not a single gatekeeper role.
• End-to-end audio → MusicXML/MIDI so the group can iterate on parts without a blank staff.
• Rhythm correction trained on real MusicXML—output targets musician-readable charts, not a robotic onset dump.
• Web + iOS + one API, optional cloud-backed assets with LRU-style retention thinking, and Auth0 so identity isn’t bolted on late.

What we learned

• Music21 needs careful timing and duration modeling to turn ML output into legible scores.
• Basic Pitch is a strong base; post-processing (grid, merge, correct) is where quality shows up.
• SPAs + Auth0 need a single canonical origin per environment and redeploy when VITE_* changes.
• Splitting static hosting from a CPU/GPU-heavy API fits this problem—even with more moving parts.

What's next for CodeForChord

Product & ML

• Stronger ML for rearrangement — voicings, voice-leading, and suggestions that feel like a human arranger, not only rule-based transpose/mode/simplify.
• Stronger ML for audio → sheet — instrument-aware models, cleaner polyphony, and outputs that match how charts are normally written with minimal cleanup.
• Editing & collaboration — in-browser note fixes, shareable charts for the band, lightweight real-time feedback for rehearsal.

Engineering: alignment, quality, and maintainability

• Code alignment across the stack — keep web, iOS, and API speaking the same contracts: shared naming for endpoints, query params, and response shapes; OpenAPI / FastAPI schemas as the source of truth; client types or generated stubs where it pays off.
• API–UI parity — ensure every surfaced control (e.g. correction strength, output types) maps cleanly to documented routes and defaults so behavior doesn’t drift between Vue, Swift, and the server.
• Monorepo discipline — consistent linting/formatting (Python + JS/Swift), dependency hygiene, and small shared docs (env templates, deploy checklist) so contributors don’t guess.
• Testing & CI — broader API integration tests for the audio→sheet pipeline; contract tests for critical JSON/MusicXML payloads; keep GitHub Actions (e.g. iOS xcodebuild) green on main.
• Observability & performance — structured logging, timing around heavy steps (inference, MusicXML build), and caching where safe so cloud cost and latency stay predictable.
• Security hardening — tighten CORS and JWT usage in production, secrets only in env/secret stores, and periodic review of Auth0 + storage access patterns.

Built With

• azure
• fastapi
• machine-learning
• mongodb
• node.js
• python
• quantization
• swift
• tailwindcss
• vue.js