Strudel-Synth: Synthetic MIDI Decompilation

• Strudel-Synth is a synthetic paired dataset that generates MIDI and Strudel program pairs via LLM-driven code generation, cleaning, and MIDI rendering.
• The dataset employs rigorous regex rewrites and AST-based pruning to ensure the code is idiomatic, executable, and musically faithful.
• It offers diverse program structures—from event-level to arrangement-level—enabling the model to learn readable and editable live-coding abstractions.

Searching arXiv for the primary paper and nearby context on Strudel/Decomposer. Strudel-Synth is a synthetic paired dataset introduced as the supervised backbone of DECOMPOSER, a framework for MIDI-to-Strudel decompilation. In that setting, the task is to recover executable, editable Strudel programs from symbolic MIDI, but Strudel is a low-resource DSL with very little naturally paired MIDI-code data. Strudel-Synth addresses that scarcity by assembling a large corpus of (Strudel [code](https://www.emergentmind.com/topics/karpathy-agent-code), MIDI) pairs through LLM generation, program cleaning, execution, and MIDI rendering, thereby providing a “warm start” for supervised fine-tuning before reinforcement learning on unpaired MIDI (Kim et al., 2 Jul 2026).

1. Conceptual role within symbolic music decompilation

DECOMPOSER instantiates symbolic music decompilation as MIDI-to-Strudel decompilation: the model takes symbolic MIDI as input and produces a program in Strudel that reconstructs the input when executed. The paper identifies two core difficulties. First, Strudel is a low-resource language; the public web crawl yielded only 688 non-trivial human-authored programs, which is too small for large-scale supervised learning. Second, optimizing only for reconstruction faithfulness can collapse to unreadable note-by-note transliteration. Strudel-Synth is the synthetic corpus created to mitigate both problems (Kim et al., 2 Jul 2026).

The dataset serves two explicit functions. It provides a supervised fine-tuning (SFT) warm start, allowing the model to learn valid, idiomatic Strudel before RL begins. It also supplies synthetic musical/program diversity, exposing the model to several distinct program idioms rather than a single canonical representation. The paper emphasizes that the decompilation task is underdetermined: many different Strudel programs can render to the same music. Accordingly, Strudel-Synth includes event-level transliterations, pattern-based abstractions, shared-structure programs with reusable variables, and arrangement-level programs with arrange().

A plausible implication is that Strudel-Synth is best understood less as a dataset for direct symbolic transcription and more as a dataset for learning a structured prior over executable live-coding programs. Its significance lies in teaching the model which Strudel programs are not only compilable, but also stylistically idiomatic and editable.

2. Generation, cleaning, and rendering pipeline

The corpus is built in three stages: conditioned generation with a frontier LLM, cleaning and dead-voice pruning, and rendering to MIDI. The generation model is Claude-Opus-4.6, prompted to write complete, idiomatic Strudel programs under two independent seeds: S_music, which specifies musical content, and S_code, which specifies coding style. The model is instructed to generate deterministic, headless-compatible Strudel only, excluding randomness, visuals, sliders, external samples, and constructs unsupported by the runtime. The reported decoding settings are temperature = 1.0, max new tokens = 4096, and extended thinking disabled (Kim et al., 2 Jul 2026).

Generated code is then cleaned. The first cleaning stage applies deterministic regex rewrites to fix recurring errors. Table 4 reports that these rewrites correct roughly 37% of generated programs at least once. The documented rewrite targets include invalid sound aliases such as gm_electric_piano_1 -> gm_epiano1 and shaker -> sh, voicing misuse such as .voicings(...) -> .voicing(), certain malformed note(...) and n(...) constructions around chord material, lambda-style .note(x => ...), empty .note() after tonal operators, some broken rootNotes/note ordering problems, arrange() length guards that cap section lengths at ≤ 2 cycles and total arrangement length at ≤ 12 cycles, and .struct("0 0") -> .struct("1 0") when no trigger appears.

The second cleaning stage is AST-based pruning. After regex cleanup, programs are parsed with the Acorn JavaScript parser. Using the AST, the pipeline identifies top-level musical voices, including $: labeled statements, stack(...) arguments, and arrange(...) tracks. Each voice is rendered in isolation; voices that emit no MIDI events are pruned, along with declarations used only by them. A program is retained only if at least one voice survives.

Rendering is performed through the Strudel runtime. The runtime queries the pattern over a fixed 90-second window, finds the fundamental period using Knuth–Morris–Pratt, keeps only the first complete loop, and serializes the result to MIDI. Renderings shorter than 2 seconds are discarded because they are usually degenerate. This pipeline converts LLM-generated source code into executable paired data while filtering out silent or malformed examples.

3. Musical conditioning and programmatic diversity

Strudel-Synth is explicitly designed to vary along two orthogonal axes: musical content and code style. The musical seed, S_music, is built from metadata drawn from EveryNoise, TheoryTab, and MidiCaps. Table 5 lists three conditioning regimes: 1 attribute with genre only; 5 attributes with genre, key, tempo (BPM), beats per bar, and chord progression; and 7 attributes with genre, key, mood, tempo, beats per bar, instrumentation, and chord progression (Kim et al., 2 Jul 2026).

The code-style seed, S_code, chooses among several idiomatic Strudel organizations. In the $: ...` mode, programs contain **3–5 top-level `$: layers*, with one musical layer per statement and no top-level stack() or arrange(). In the stack(...) mode, programs contain a single top-level stack(...) with **3–5 inner streams, each looping within **4–8 cycles. In the arrange(...) mode, programs contain **2–4 sections, each **2–3 cycles, with total length at most **12 cycles*. The generation process may also condition on reference templates extracted from crawled Strudel programs, but these templates guide only style and organization; the model is still instructed to compose new music from scratch.

Appendix A.1 organizes the resulting code into four representative abstraction levels. Event-level transliteration mirrors MIDI events directly in mini-notation through explicit drum hits, literal note lists, and spelled-out rests. Pattern-level abstraction compresses repeated material using operators such as chord() and struct(). Shared structure and layering define reusable harmonic objects, such as let chords = chord(...), and distribute them across simultaneous voices using stack(). Arrangement-level organization names voices once and combines them over time with arrange(), making section structure explicit and editable.

These forms are central to the dataset’s purpose. The paper treats Strudel not merely as a target serialization format, but as a live-coding language whose outputs should retain meaningful internal structure. A plausible implication is that Strudel-Synth encodes a notion of “good decompilation” that goes beyond event recovery and includes reusable abstractions, layered coordination, and form-level organization.

4. Corpus statistics and preprocessing outcomes

The retained dataset contains 21,174 paired examples, split into 20,152 training examples and 1,022 test examples. The rendered MIDI fragments are short musical excerpts, averaging about 24 seconds in duration and spanning 2s to 90s before trimming. The corpus covers 122 of the 128 General MIDI instruments and averages about 3.7 instruments per song (Kim et al., 2 Jul 2026).

Quantity	Value
Total (MIDI, code) pairs	21,174
Train split	20,152
Test split	1,022
Avg. lines of code (train/test)	52.20 ± 20.88 / 52.46 ± 21.70
Avg. number of instruments (train/test)	3.73 ± 1.22 / 3.68 ± 1.26
Avg. duration (train/test)	24.17 ± 19.03 s / 24.10 ± 18.70 s

The preprocessing stack also defines the runtime semantics of the paired data. The headless Strudel execution server executes programs, returns symbolic note events, serializes those events to MIDI, and exposes AST parsing for analysis and cleaning. For MIDI serialization, Strudel sounds are mapped to General MIDI programs for melodic instruments, percussion is mapped to channel-9 drum notes, note names and numeric pitches are converted to MIDI note numbers, and gain and velocity are soft-clipped into the MIDI velocity range.

The paper notes that the dataset is about 30× larger than the 688 non-trivial human-authored Strudel programs found in the web crawl. That scale difference is one of the clearest indicators of why synthetic generation is central to the overall method rather than an auxiliary convenience.

5. Use in training and its interaction with reinforcement learning

Strudel-Synth is used only for the SFT stage of DECOMPOSER. In that stage, the model is trained on paired examples (x^*, y^*), where x^* = C(y^*) is the MIDI rendered by the Strudel runtime and y^* is the corresponding Strudel program. The supervised objective is standard next-token log-likelihood:

%%%%2%%%%

The paper states that this stage gives the model a prior over executable Strudel code and prevents RL from collapsing into degenerate short outputs. The training set of Strudel-Synth is split into two disjoint halves of about 10K each: one half for SFT, and one half for RL-related use or validation-like support; the RL stage itself can also incorporate unpaired MIDI from LMD (Kim et al., 2 Jul 2026).

RL is then performed on unpaired MIDI. The framework optimizes two rewards. The faithfulness reward compares rendered MIDI $\hat{x}=C(y)$ to the input x using multi-instrument onset F1, requiring matching pitch, onset within ±50 ms, and the same General MIDI program number. The readability reward is a scalar score produced by an LLM under a 12-item checklist. The paper defines a gated reward,

%%%%3%%%%

and explicitly states that Strudel-Synth is not itself the reward mechanism, but that it makes the reward-based optimization possible.

The ablation claims are categorical. Without SFT, RL collapses to short literal note lists, the reward plateaus early, and outputs are compilable but musically impoverished. With SFT, the model learns executable idiomatic code, and RL can trade off faithfulness and readability. In that sense, Strudel-Synth functions as the structural prior that keeps search in a productive region of program space.

6. Distinctions, limitations, and neighboring research directions

Despite the word “Synth” in its name, Strudel-Synth is not a neural audio synthesizer and not a preset-search interface. It is a synthetic corpus of paired Strudel programs and rendered MIDI for program induction. That distinguishes it from systems such as SynthScribe, which is a full-stack, multimodal synthesizer exploration and sound-design system built on top of the U-He Diva synthesizer and supports preset retrieval, user-centered genetic mixing, and example-guided preset modification (Brade et al., 2023). It is likewise distinct from Sound2Synth, which addresses synthesizer parameter estimation for Dexed by inferring preset parameters from rendered audio (Chen et al., 2022), and from multi-instrument MIDI-to-audio systems based on Transformer spectrogram prediction and GAN inversion (Hawthorne et al., 2022). A plausible implication is that Strudel-Synth belongs primarily to symbolic decompilation and program synthesis, even when it interfaces with rendered musical outcomes.

The paper also makes several limitations explicit. Synthetic bias is inherent because the corpus is generated by Claude-Opus-4.6, so program style may reflect the generator’s own idioms and biases. Cleaning heuristics are imperfect; regex rewrites are heuristic and may occasionally modify already-valid programs, although cleaned outputs are revalidated afterward. There is a short-form bias, since most examples are short fragments around 24 seconds, and long-form structure is underrepresented. There is also a dataset mismatch with real-world MIDI: synthetic paired data is useful for SFT but does not fully solve generalization to corpora such as LMD or NES-MDB. Coverage limitations remain because the dataset spans 122/128 GM instruments, not all possible instrumentation, and it excludes live-coding constructs unsupported by the headless execution pipeline. Finally, the readability rubric is checklist-based and may privilege some abstractions over others.

Within DECOMPOSER, however, the dataset is treated as the critical enabling resource. It provides executable examples across $:, stack(), arrange(), mini-notation, chord abstractions, shared variables, and layered structures, thereby teaching the model not only to reconstruct MIDI, but to emit code that is more readable, editable, and structurally meaningful. That is the central sense in which Strudel-Synth matters: it operationalizes paired supervision for a low-resource music programming language by synthesizing the code-data alignment that the web does not provide.