Solo Developer's 125M Model Auto-Completes Piano Playing on iPhone

The approach can be compared to a tool familiar to developers. Just as GitHub Copilot uses a few lines of code or a comment as a prompt to fill in the rest, this model takes a handful of notes played by the user on a keyboard as a prompt and continues the piece. But unlike Copilot, which is a front-end product running on third-party models chosen by the user (GPT, Claude, Gemini, etc.), RollTab runs a model the developer built entirely on the device itself. All inference happens inside the iPhone, with no server communication.

The developer said reaching this result took roughly a year and fourteen rounds of experimentation. "Think GitHub Copilot, but for piano" — a single line at the start of his blog post that sums up the project's goal.

How do you break down MIDI so a model can learn from it

A MIDI file isn't recorded sound but a sequence of events like "key pressed," "key released," and "pedal pressed." The biggest challenge arose in converting these events into a token sequence a transformer could read. Creating separate note-on and note-off events for every note often caused the model to forget the note-off signal, resulting in notes that kept ringing indefinitely — a problem that was especially severe in small models aimed at near-real-time performance.

After much trial and error, the developer settled on representing each note as a single unit. Each note carries four categorical values together — time since the previous note (delta_onset), pitch, duration, and velocity — reducing what would have been four passes through the transformer backbone per field down to one pass per note. He explained that this design change was the key factor enabling the 108-notes-per-second speed. The sustain pedal was likewise simplified during preprocessing rather than encoded as a separate event, with pedal-down time folded into the note's actual duration.

Data quality over quantity — performance got worse after a 5x increase

The final dataset consisted of several hundred thousand MIDI files, mostly public-domain classical music, totaling about 300 million note events. The developer also tried expanding the data roughly fivefold, but the resulting model's quality actually declined. His conclusion was that curation and selection mattered more than simply adding more data.

This isn't the only project tackling music generation models. MiniMax releases open-weights music model MiniMax Music3, generating a full 5-minute song from lyrics alone

Refining quality through preference learning

Continuing a piece isn't a problem with a single correct answer. Cross-entropy training, which treats only the single next note in a held-out piece as the "correct" answer, teaches the basic grammar of music but has limits in producing completions that actually sound natural. To address this, the developer built an evaluation system using Gemini 3.5 Flash to make pairwise comparisons of which of two completions was better, and used this preference data for DPO (Direct Preference Optimization) post-training. He evaluated how well a completion picked up the prompt and how musically good it was on its own as separate criteria, and used the former as the core signal for DPO.

After applying DPO, the model was chosen as better than the original base model in over 69% of pairwise evaluations. Results from experiments varying the beta (β) value were as follows.

β value	Result
0.01	Model performance improved
0.03	Model performance improved (optimal range)
0.10	Excessive drift from the original, performance degraded

The developer said that among noisy preference judgments, a "consensus dataset" keeping only pairs where evaluators consistently agreed produced the best results in these experiments.

Getting it to run in real time on an iPhone

The finished model was converted from PyTorch to Core ML and its weights were quantized to INT8. The developer noted that the Core ML runtime is somewhat slow the first time the app runs, as it optimizes the model for the device's hardware. Although the model was trained with a context of up to 512 notes, to support longer play sessions, when the context approaches its limit, the system keeps only the most recent 384 notes and rebuilds the context from that point.

App Store review reportedly took 11 days for the first version's approval. A new version now awaiting review lets users choose among several sampling methods, including top-k, top-p, min-p, XTC, top-h, and Mirostat v2. These sampling options are settings that determine how the model balances diversity and stability when choosing the next note.

How to try it

RollTab was released for free for users who have a MIDI keyboard and an iPhone or iPad. The usage flow, as far as can be confirmed from the source, is simple. First, connect a MIDI piano to an iPhone or iPad via cable or wirelessly. Then launch the RollTab app and play a few notes briefly on the keyboard. These few notes serve as the prompt given to the model, which picks up from there and automatically generates the rest on the device.

According to the source, the number of notes given as a prompt affects the quality of the result. In the developer's listening evaluations, a 4-note prompt was the most difficult due to insufficient context, an 8-note prompt was somewhat better, and prompts of 16 to 32 notes let the model grasp the flow more reliably. For example, playing the opening bars of a favorite song produces an improvisation that continues in that style, and pausing mid-improvisation at a sticking point lets the model suggest what comes next.

Editor's take

What this project shows is that a solo developer, without a large research lab, can produce a practical result by pursuing one narrow problem all the way through. Existing symbolic music generation research such as Aria, Moonbeam, and MIDI-GPT generally assumes large-scale models and research infrastructure. The developer said he compared his approach to existing papers like Aria, Moonbeam, and MIDI-GPT only after completing the work — and that ordering itself is notable. Rather than absorbing existing literature first, he rediscovered the problem through direct trial and error and validated his approach afterward.

There's a pattern familiar to anyone who has worked with small on-device models: the expectation that more data always leads to better results is often betrayed in practice. The case in this project where performance dropped after a fivefold increase in data reaffirms — across text, image, or music models alike — that well-curated small datasets tend to beat large unfiltered ones, regardless of domain.

For teams in Korea evaluating on-device generative models, there are two takeaways worth noting from this case. One is that preference-based post-training methods like DPO are valid not just for language models but for time-series-style generation problems as well. The other is that deployment-stage refinements like Core ML quantization and context reconstruction can shape real-world performance as much as the model design itself. In other words, time spent on the deployment pipeline can end up exceeding time spent reproducing the paper's methods.

In the coming months, more solo developer projects are likely to emerge that move narrow creative domains — composition assistance, lyric continuation, choreography sequencing, and the like — onto devices in similar ways. As quantization tools for Core ML and similar on-device runtimes keep getting easier to use, the barrier to running 100M-scale models in real time on smartphones continues to fall.