Advanced Functional Prototype · Reference hardware validated: Raspberry Pi 4 · Roland via USB-MIDI2026

Piano Core

Smart Piano Learning & Playback System

My role

Product Architecture · Realtime Musical Core · ESP32/Firmware Integration · Web Interface · Reliability Engineering

01

Project overview

Piano Core is a local-first smart piano appliance. Connected to a compatible digital piano over USB-MIDI, it turns the instrument into a modern learning, playback and interactive piano system without depending on a cloud service.

The long-term product target is a consumer device: unbox, connect power, connect the digital piano via USB-MIDI, join Wi-Fi and open the system from a phone, tablet or PC. The user never needs to understand Raspberry Pi, Linux, SSH, IP addresses, ports, MIDI internals or systemd.

One architectural rule keeps the product honest: Piano Core remains the single musical authority. A canonical musical state and timeline drive playback and practice; browser rendering is never musical authority, renderers cannot advance Practice, and a UI reconnect or reload simply recovers from the authoritative state.

02

Real product screenshots

Only real product screenshots will be placed here—no mockups or stock imagery.

01

Local web interface on phone, tablet and PC

Only real product screenshots will be placed here—no mockups or stock imagery.

/projects/piano-core/desktop-01.webp
02

Guided Practice with wait-for-note targets

Only real product screenshots will be placed here—no mockups or stock imagery.

/projects/piano-core/mobile-01.webp
03

ESP32 LED keyboard during playback

Only real product screenshots will be placed here—no mockups or stock imagery.

/projects/piano-core/desktop-02.webp
04

MIDI library search across the indexed catalog

Only real product screenshots will be placed here—no mockups or stock imagery.

/projects/piano-core/mobile-02.webp

03

System architecture

Physical Digital Piano

Roland reference instrument

Piano Core Appliance

Raspberry Pi 4 · StateStore · Playback Core · LibraryService

Realtime API & Events

Canonical musical state and timeline

Renderers & Keyboard

Phone · Tablet · PC · ESP32 LED keyboard

04

Project status

Built

  • Physical USB-MIDI input from the digital piano
  • Canonical StateStore as the single musical authority
  • Deterministic Playback Core
  • LibraryService with MIDI indexing, search and resolution — 100,000+ indexed MIDI songs
  • Guided Practice with Wait-For-Me behavior and note/chord targets
  • Practice semantics: repeated-note release, wrong-note rejection and chord completion
  • Clear ownership between practice and playback activity
  • ESP32 LED keyboard integration with calibrated 88-key / 196-LED mapping
  • Responsive local web/API for phone, tablet and PC
  • Persistent appliance and device identity
  • Persistence across restarts, reboots and application replacement
  • DHCP-independent operation after reliability work

In active development

  • Consolidating the verified reference prototype toward the consumer product path defined in the roadmap below

Planned

  • Premium UI V2 with WebGPU-first rendering
  • Professional sheet music, falling notes and hybrid visualization
  • Realistic 3D hands, fingering engine and hand-motion planning
  • Adaptive learning
  • QR Wi-Fi onboarding and captive provisioning
  • Signed updates with rollback
  • Consumer enclosure and custom carrier board

05

Engineering decisions

Why does Piano Core stay the single musical authority?

One canonical musical state and timeline keep playback and practice deterministic. Renderers — phone, tablet, PC or future premium UIs — can display and interact, but cannot advance Practice on their own. When a UI reconnects or reloads, it recovers from the authoritative state instead of guessing.

Why a local appliance instead of a cloud product?

Practice, playback and the indexed library run locally on the appliance, and the appliance keeps its identity and operation independent of DHCP behavior after the reliability work. The musical core does not depend on a cloud service.

Why a separate ESP32 LED controller?

The calibrated 88-key / 196-LED mapping runs on dedicated ESP32 hardware, keeping keyboard lighting independent from the musical core on the Raspberry Pi.

06

Challenges solved

  • 01Keeping one canonical musical state across UI reconnects and reloads
  • 02Precise practice semantics: wait-for-note targets, repeated-note release, wrong-note rejection and chord completion
  • 03Appliance persistence across restarts, reboots and application replacement
  • 04DHCP-independent operation for reliability in real home networks

07

Technology stack

Reference hardware

  • Raspberry Pi 4
  • Roland digital piano via USB-MIDI
  • ESP32 LED keyboard controller
  • Calibrated 88-key / 196-LED mapping

Musical core

  • Canonical StateStore
  • Deterministic Playback Core
  • LibraryService · MIDI indexing/search/resolution

Learning

  • Guided Practice (implemented foundation)
  • Wait-For-Me behavior
  • Note/chord targets & completion semantics

Delivery

  • Responsive local web/API
  • Realtime events
  • Persistent appliance identity

08

What it demonstrates

Piano Core demonstrates my ability to build a complete local-first appliance product: a canonical musical core, deterministic playback, real guided-practice semantics, dedicated LED hardware and appliance-grade reliability — the verified foundation for the consumer roadmap ahead.

Need a similar system?

I can design and build a solution around your workflow, team, and business goals.

Discuss your project