Papers
Topics
Authors
Recent
Search
2000 character limit reached

Decomposer: Learning to Decompile Symbolic Music to Programs

Published 2 Jul 2026 in cs.LG, cs.AI, and cs.SD | (2607.01849v1)

Abstract: Musical performance involves executing a set of high-level musical instructions, yet recovering those instructions from the performance is a challenging inverse problem. We present Decomposer, a post-training framework for symbolic music decompilation: the task of recovering executable, editable music programs from symbolic music. We instantiate the task as MIDI-to-Strudel decompilation, where the model takes symbolic MIDI as input and produces a program in Strudel, a music programming language, that reconstructs the input when executed. The task poses two challenges: Strudel is a low-resource language with little naturally paired MIDI-code data, and optimizing faithful reconstruction of MIDI alone can collapse to unreadable note-by-note transliteration. We address these challenges in two stages. First, we construct Strudel-Synth, a synthetic corpus of paired Strudel programs and rendered MIDI, and use it for supervised fine-tuning. Second, we refine the model with reinforcement learning on unpaired MIDI, optimizing rewards for both MIDI reconstruction faithfulness and code readability. Our evaluation across synthetic and real-world MIDI benchmarks shows that Decomposer achieves substantially higher MIDI reconstruction faithfulness than closed-source LLMs while producing more readable and diverse code than the heuristic converter.

Summary

  • The paper introduces a two-stage framework combining supervised fine-tuning and reinforcement learning to generate human-editable Strudel code from MIDI input.
  • The methodology leverages a synthetic paired dataset and execution-based rewards to optimize both code readability and output faithfulness.
  • Experimental results show significant improvements in compile rates, onset/instrument F1 scores, and code diversity, with robust generalization across musical genres.

Decomposer: Learning to Decompile Symbolic Music to Programs

Problem Definition and Motivation

The inverse problem of translating rendered music into its high-level, human-editable structure is a longstanding challenge central to symbolic music, analogously to established decompilation problems in other artifact domains (e.g., binaries, raster graphics). The paper introduces the task of symbolic music decompilation: recovering editable, executable code in a music programming language (Strudel) from symbolic music input (MIDI). The rationale is grounded in both practicality and usability: rendered MIDI is abundant, but editable code is far more valuable for downstream uses (editing, manipulation, integration with code-based tooling). However, functional output equivalence alone is insufficient—readability and structural abstraction are essential for effective code recovery.

MIDI-to-Strudel decompilation presents unique challenges. There is a lack of large, naturally paired (MIDI, code) data for training. Strudel, a low-resource DSL, exists primarily for algorithmic composition and live coding, representing musical content programmatically through patterns and abstractions, in contrast to event-based MIDI. Existing approaches either yield unreadable, functionally faithful code via direct note-level transliteration (heuristic conversion) or produce readable but poorly grounded programs (frontier LLMs not adapted to the task).

Methodology

Two-Stage Post-Training Framework

The DECOMPOSER framework is designed as a two-stage post-training procedure for open-weight LLMs, specifically targeting MIDI-to-Strudel decompilation:

  1. Supervised Fine-Tuning (SFT): A synthetic paired dataset, STRUDEL-SYNTH, is constructed by prompting a frontier LLM (Claude-Opus-4.6) to generate Strudel programs under varied musical and code-style constraints, followed by deterministic cleaning, dead-voice pruning, and headless rendering to obtain the corresponding MIDI. This corpus (21,174 (MIDI, Strudel) pairs) provides sufficient supervision for initial model adaptation.
  2. Reinforcement Learning (RL): After SFT, execution-based RL further optimizes the model on unpaired MIDI, leveraging only the MIDI input and Strudel runtime for reward calculation. The composite reward balances MIDI reconstruction faithfulness (instrument-aware onset F1) and code readability (a 12-point LLM-judged rubric). The RL objective is optimized using Group reward-Decoupled normalization Policy Optimization (GDPO), which ensures balanced multi-objective training by per-component normalization before aggregation.

The composite reward is strictly gated on successful code execution. Only executable programs receive non-penalized faithfulness/readability scores, thus driving the model toward practical, correct code.

Data Pipeline

Synthetic data generation relies on prompt-based control of musical attributes (genre, mood, key, tempo, meter, chords, instrumentation) and program idioms (e.g., mini-notation, layered stack, arrange), providing strong coverage of code patterns encountered in Strudel practice. Generated code is systematically cleaned using regex and AST parsing, with non-productive musical voices pruned. The resultant set is considerably more diverse and idiomatic than what web crawl could provide.

Input/Output Representation

MIDI is serialized as instrument-part note events grouped by instrument, with pitches rendered as musical note names and onset times normalized to 'cycle' units matching Strudel's rhythmic abstractions. The model's prompt enforces adherence to Strudel idioms, pattern abstraction, and code style rules relevant for both compilation and human readability.

Experimental Results

Faithfulness–Readability–Diversity Tradeoff

Quantitative evaluations investigate faithfulness (compile rate, onset F1, instrument F1), code readability (LLM-judged rubric, average rank), and code diversity (intra-method CodeBLEU self-similarity) across synthetic (STRUDEL-SYNTH) and real-world (LMD) benchmarks. Baselines include: (a) the heuristic note-level converter (maximal faithfulness, minimal readability), (b) closed-weight frontier LLMs (mid-range readability, low faithfulness), and (c) vanilla Qwen3 models.

Key findings:

  • Faithfulness: DECOMPOSER (8B) achieves near-perfect compile rate and the highest Onset/Instrument F1 scores across all settings, substantially outperforming both frontier LLMs (by +0.16–0.32 Onset F1) and open-weight models without adaptation.
  • Readability: Code produced by DECOMPOSER scores comparably to frontier LLMs (rubric 0.61–0.74), while the heuristic converter remains an order of magnitude lower (0.05–0.09).
  • Diversity: RL-based post-training preserves idiomatic diversity, as measured by SelfCB, avoiding the collapse to fixed templates seen with heuristic methods.

Notably, SFT alone is insufficient for real-world MIDI; execution-based RL yields strong improvements on out-of-domain data without requiring new code annotations.

Ablation and Generalization

Ablation studies clarify the importance of the readability reward and SFT warm start. Increasing the weight of readability improves code quality but can sacrifice faithfulness. Without SFT, RL plateaus at degenerate solutions (verbosity and minimal structure; low reward). Generalization to other datasets (GigaMIDI, NES-MDB, Nottingham, longer LMD) shows robust transfer, with DECOMPOSER maintaining faithfulness and readability advantages over all baselines.

Genre-wise analysis on ModArchive reveals systematic performance gaps: genres with regular rhythmic structure (e.g., electronic, dance) are reconstructed more faithfully than those with irregular timing and dense or expressive textures (e.g., jazz, orchestral, chiptune).

Theoretical and Practical Implications

DECOMPOSER demonstrates that post-training LLMs can acquire the ability to invert the symbolic music process, yielding editable, high-level code from MIDI. This aligns with broader trends in program synthesis, where decompilation is positioned not as a mere transliteration task, but as reconstructing abstract, human-usable structure with verifiable behavioral equivalence.

Implications:

  • Editable Music Representations: Converting MIDI to Strudel code enables code-based music editing, facilitating programmatic manipulation, creativity support, and integration with AI-augmented music tooling or live coding contexts.
  • Music Structure Reasoning: Mid-level code structures offer improved substrates for both human and model-based music analysis (e.g., motif discovery, music education, abstracted reasoning).
  • Expanding Modality Coverage: The reward design (execution-based RL, LLM-judge-based metrics) and synthetic corpus construction are directly extensible to other low-resource code decompilation modalities (e.g., decompiled audio effects, UI reconstruction).

Future Research Directions

The paper identifies several limitations and avenues for further development:

  • Reward Conditioning: The fixed readability rubric, while effective, is coarse; future work could use input-conditional, fine-grained evaluation schemes or multi-LLM adjudication.
  • Long-Form and Complex Music: Scaling to compositions with significant recurrence and long-range temporal structure will require both larger, more structured datasets and adaptively designed RL rewards.
  • Diversity Optimization: Explicitly incorporating output diversity into RL objectives remains unexplored.
  • Creative Trace Recovery: Beyond recovering a terminal program, inferring a creative process (progressive code evolution) could offer richer models of musical composition and interaction.

Conclusion

DECOMPOSER advances the state-of-the-art in symbolic music decompilation by integrating synthetic data generation, supervised adaptation, and execution-based RL with multi-objective reward. The resulting system produces Strudel programs from MIDI with superior faithfulness and readability relative to both heuristic and LLM-based baselines, while maintaining output diversity and generalizing across musical domains. This work establishes a methodological and practical precedent for program synthesis with multi-faceted, execution-grounded evaluation in low-resource code domains, with immediate applicability for algorithmic music composition, music education, and AI-augmented creativity tools (2607.01849).

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

What is this paper about?

This paper is about turning digital music notes back into easy-to-edit code. The authors build a system called DECOMPOSER that takes MIDI (a common digital format for music notes) and writes a short, readable program in a music language called Strudel. When you run that Strudel program, it plays the same music. The big idea: don’t just copy every note one by one—recover the patterns and structure (like repeating rhythms or chord progressions) so people can understand and edit the music more easily.

What questions did the researchers ask?

They focused on two simple questions:

  • Can we turn MIDI into Strudel code that plays the same music (faithfulness)?
  • Can that code be short, clean, and easy for people to understand and change (readability)?

They also wondered how to do this when there isn’t much real training data of MIDI paired with Strudel code.

How did they do it?

Think of this like translating a cake into a recipe: instead of listing every grain of sugar (every note), you want steps like “mix,” “bake,” and “decorate” (musical patterns, chords, repeats). The team trained an AI in two stages:

  • Stage 1: Supervised fine-tuning (learning by example)
    • Problem: There aren’t many real examples of MIDI paired with Strudel code.
    • Solution: They created their own dataset called STRUDEL-SYNTH. They asked a strong AI to write thousands of Strudel programs, then ran those programs to get matching MIDI files. This gave them 21,174 paired examples to teach their model how to write valid, idiomatic Strudel code.
  • Stage 2: Reinforcement learning (trial-and-error with rewards)
    • The model tries writing several different Strudel programs for a given MIDI.
    • Each program is run to produce music; the model gets scores based on:
    • Faithfulness: Does the produced music match the original MIDI’s notes and timing (like checking if the starts of notes and instruments line up)?
    • Readability: Does the code use clean structure, patterns, and chords, instead of a messy note-by-note dump?
    • If the code doesn’t even run, it’s penalized. Over time, the model learns to write code that both plays the right music and looks clean.

In everyday terms: first, they taught the AI the “grammar” and “style” of Strudel using synthetic examples. Then they let it practice on lots of MIDI, rewarding it when the result sounds right and the code is tidy and editable.

What did they find, and why is it important?

Here are the key results:

  • Higher faithfulness than general-purpose AI models: DECOMPOSER’s code reproduces the input MIDI more accurately than strong, closed-source LLMs that weren’t specially trained for this.
  • Much better readability than a simple converter: There’s a “cheat” method that just lists every note in code—it’s faithful but unreadable. DECOMPOSER avoids that, using patterns and structure so humans can understand and edit the music.
  • Works on both synthetic and real-world MIDI: It doesn’t just do well on its own training-style data. It adapts to real songs, too.
  • Scales without paired data: The second stage (trial-and-error learning) only needs MIDI, not matching code. That means it can keep improving on huge music collections that don’t have code.
  • Tunable tradeoff: By adjusting how much they reward readability versus faithfulness, the system can produce either more exact transcriptions or more abstract, creative code, depending on what users want.

Why this matters: Musicians, educators, and developers can get an editable “recipe” for a piece of music—patterns, chords, layers—instead of a flat list of notes. That makes it easier to tweak, remix, learn from, or build tools around the music.

What could this change in the future?

  • Easier music editing and live coding: Converting MIDI into structured code lets people change high-level ideas (like chord progressions or rhythms) quickly, rather than moving individual notes around by hand.
  • Better music understanding: Structured programs make the hidden patterns in music visible—useful for learning, analysis, and teaching.
  • A path to audio-to-code: Combine automatic transcription (audio → MIDI) with DECOMPOSER (MIDI → code) to go from sound recordings to readable music programs.
  • Room to grow: The paper notes limits—current versions work best on short segments, the readability checklist could be smarter, and longer works with multiple sections will need new ideas. But because the learning can use any unpaired MIDI, it can keep getting better as more data is added.

In short, DECOMPOSER is like a translator that turns raw musical notes into clear, editable instructions. It helps computers and people work with music at a higher level, making it easier to understand, modify, and create.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a consolidated list of what remains missing, uncertain, or unexplored in the paper, phrased to guide concrete future investigations.

  • Reward design limitations:
    • Faithfulness reward uses only multi-instrument onset F1; it ignores note durations, velocities, tempo curves, articulation, sustain pedal, pitch bend, and other controllers. How to incorporate duration, dynamics, and expressive timing into execution-based rewards without destabilizing RL?
    • The ±50 ms onset tolerance may bias the model toward quantized timing. What tolerance schedules or continuous timing penalties better reflect human-perceived timing accuracy?
    • Readability reward is a binary 12-item LLM-judged rubric with uniform weights; item validity, inter-rater reliability, and calibration are not validated against human experts. How to build a calibrated, human-grounded, and reliability-tested readability metric?
    • Readability rewards are input-agnostic; they may favor harmonic abstractions even for percussive or monophonic material. Can the rubric be made input-conditional or genre/instrument-aware?
    • The composite objective uses fixed weights (e.g., w2 = 0.5); there is no principled mechanism to set or adapt weights per input or user intent. Can constrained or Pareto multi-objective RL yield controllable trade-offs?
    • No explicit diversity reward; diversity is only monitored (Self CodeBLEU). How to design structural/code diversity rewards that avoid superficial token-level variation while preserving faithfulness?
  • Evaluation gaps:
    • No human study assessing readability, editability, or user satisfaction; both rubric and listwise ranking rely on LLM judges. How well do LLM-based readability scores correlate with human composers’ judgments and editing speed?
    • Lack of task-based evaluations (e.g., time-to-edit a chord progression, re-voice, reharmonize) to quantify “editability” benefits over MIDI or heuristic code.
    • Faithfulness metrics at eval time (Onset/Frame/Inst F1) still underweight dynamics and controllers. Can evaluation incorporate velocity histograms, duration overlap F1, controller accuracy, or perceptual audio-level similarity after rendering?
    • No evaluation of structural recovery quality (e.g., chord/scale/motif detection accuracy in the decompiled code vs. ground truth), beyond MIDI event matching.
  • Dataset and training data concerns:
    • STRUDEL-SYNTH is synthetic and generated by a single frontier LLM, possibly biasing style, idioms, and abstractions. How does this affect generalization to human-written Strudel? Can multi-source or human-curated seeds reduce bias?
    • Cleaning pipeline removes “dead voices”; its precision/recall and downstream impact on learned code priors are not measured. Are valid but quiet/conditional voices being dropped?
    • Short duration bias (~24 s) per sample; limited exposure to long-form structure, sectional form, and development. How to curate long-form paired/unpaired corpora suitable for long-horizon RL?
    • Potential train/test leakage risks in RL on unpaired MIDI (e.g., overlapping works or near-duplicates) are not quantified. Can robust de-duplication and provenance tracking be implemented?
  • Generalization and coverage:
    • Limited generalization on longer LMD and NES-MDB indicates sensitivity to duration, platform-specific idioms (e.g., NES sound), or genre. What adaptations (curriculum, augmentation, domain-specific rewards) improve cross-corpus robustness?
    • Only Strudel is considered. How transferable is the framework to other DSLs (e.g., TidalCycles, Sonic Pi, SuperCollider) or to multi-target decompilation where users choose a target language?
    • Limited coverage of non-Western tunings, microtonal material, or irregular time/rhythm constructs not well captured by GM MIDI; how to extend decompilation to broader musical systems?
  • Representation and modeling:
    • The MidiToText representation is not fully specified; potential information loss or token-length bottlenecks for long pieces is unaddressed. Would learned MIDI encoders or structured tokenization improve grounding and scalability?
    • The model does not use a symbolic music analysis front-end (e.g., chord/beat/structure inference) to scaffold code generation. Can hybrid pipelines (analysis → code skeleton → RL refinement) improve structure recovery?
    • No exploration of larger or different base models, multimodal encoders, or pretraining on symbolic music corpora to improve input grounding.
  • RL methodology and stability:
    • RL is brittle without SFT and can collapse to note lists; sensitivity to SFT data composition and size is not studied. What minimum SFT quality/quantity is required to stabilize RL?
    • Computational cost and sample efficiency of GDPO with on-policy execution are not reported; runtime bottlenecks (Strudel execution speed) and scalability to longer inputs remain unclear.
    • Reward hacking risks (e.g., exploiting judge prompt, gaming readability by superficial formatting, or optimizing onset-only) are not probed. What adversarial tests and guardrails prevent gaming?
  • Code and runtime aspects:
    • Strudel runtime determinism and version sensitivity are assumed; cross-version reproducibility and portability (e.g., different soundfonts, GM mappings, or engines) are not tested.
    • Mapping between Strudel instruments and GM programs in MIDI is lossy; how to preserve or reconstruct timbral intent, articulations, and effects in code and in MIDI renderings?
    • Coverage of advanced Strudel constructs (functions, factories, arrange, live-coding idioms) is not quantified. Does the model over-rely on a narrow subset of idioms learned from synthetic data?
  • Long-form and interactive creation:
    • Long-form decompilation with sections, reprises, and development is unaddressed; reward shaping and memory constraints for multi-minute pieces are open.
    • “Creative trace” recovery (inferring an edit history/REPL session rather than a single final program) is posited but not explored. What supervision and rewards support trace inference?
  • Audio-to-code pipeline:
    • The proposed audio→MIDI→code path inherits transcription errors and ignores timbre/effects. Can joint optimization with differentiable synthesis or audio-level rewards enable direct audio-to-code decompilation?
    • No experiments combining state-of-the-art AMT with DECOMPOSER nor analysis of error propagation from AMT to decompilation quality.
  • Controllability and user intent:
    • No mechanism to condition decompilation on user constraints (e.g., preferred idioms, concision level, target readability score, or style). Can conditional RL or control tokens allow user-steered trade-offs?
    • Absence of per-genre or per-instrument policies; input-conditional strategies (e.g., percussive-only patterns vs. harmonic abstractions) are not modeled.
  • Benchmarks and baselines:
    • Lack of comparisons to structured pattern-extraction baselines (e.g., grammar/heuristic pattern miners) that might produce compact code beyond literal transliteration.
    • No ablation on alternative faithfulness metrics or multi-component faithfulness (e.g., combining onset, duration, velocity) to see which components drive perceived quality.
  • Reproducibility and release:
    • Details on code release, runtime environment, LLM-judge prompts, and judge model versions are not specified; LLM-judge drift threatens reproducibility. Can a fixed, open-weight judge and prompts be released?
  • Ethical and legal considerations:
    • Use of LMD/other MIDI corpora raises licensing/provenance questions for downstream code generation; copyright and training data governance are not discussed. How to audit and respect licensing in decompiled outputs?

Practical Applications

Immediate Applications

Below are practical use cases that can be deployed with today’s tools and data, leveraging the paper’s methods, datasets, and evaluation findings.

  • Bold: MIDI-to-code utility for DAWs and live coding — Sectors: music tech, software
    • Description: Convert MIDI clips into readable Strudel programs for editing, pattern abstraction, and live performance.
    • Tools/workflows: VST/AU/CLAP plugin or DAW script; “Decompile to Strudel” command; round‑trip “Strudel↔MIDI” workflow; batch conversion tool for MIDI folders.
    • Assumptions/dependencies: Reliable Strudel runtime integration; licensing of source MIDI; UI/UX for code-editing inside DAWs; timing/quantization settings to align with DAW tempo grids.
  • Bold: Code-aware music editing assistants — Sectors: music tech, creator tools
    • Description: In-DAW assistant that exposes chord progressions, repetitions, and layers as code blocks to enable high-level edits (e.g., change mode, humanize rhythms, reharmonize sections).
    • Tools/workflows: Context menu “Edit in Strudel,” parameterized macros (e.g., scale, voicing, struct operators); side-by-side code and piano-roll views.
    • Assumptions/dependencies: Stable MIDI↔Strudel invertibility for common idioms; latency low enough for iterative edits; user onboarding to Strudel syntax.
  • Bold: Readability linting and auto-refactoring for music code — Sectors: software, music tech
    • Description: Apply the paper’s rubric-as-reward criteria as a linter to improve Strudel code clarity (replace literal notes with chords/patterns, factor repetition).
    • Tools/workflows: CLI/IDE extension for Strudel; pre-commit hooks; “Refactor to patterns” one-click action.
    • Assumptions/dependencies: Access to an LLM judge or distilled classifier; guardrails to avoid changing musical semantics.
  • Bold: Curriculum materials for music education — Sectors: education
    • Description: Turn MIDI examples into concise, annotated Strudel programs to teach form, meter, harmony, and motif variation.
    • Tools/workflows: Classroom notebooks; interactive web IDE (Strudel.cc) with linked MIDI playback; assignments requiring students to modify decompiled code.
    • Assumptions/dependencies: Educator alignment on code idioms; adequate decompilation for percussion-heavy pieces; licensing of teaching MIDI.
  • Bold: MIR research assets: dataset and benchmark — Sectors: academia (MIR, ML)
    • Description: Use STRUDEL-SYNTH and the paper’s metrics (instrument-aware onset F1, rubric score) to study music decompilation and code-format understanding.
    • Tools/workflows: Public release of STRUDEL-SYNTH; standardized evaluation scripts; ablations on faithfulness/readability trade-offs.
    • Assumptions/dependencies: Community adoption; clear licenses for redistribution; reproducible Strudel runtime.
  • Bold: Structure-aware music search and retrieval — Sectors: music tech, content ops
    • Description: Index catalogs by decompiled code patterns (e.g., “ii–V–I in swing at 160 BPM” or “3-3-2 clave in percussion track”).
    • Tools/workflows: Pattern-token inverted indices; query-by-code snippets; filters by instrumentation and meter.
    • Assumptions/dependencies: Consistent pattern abstraction across genres; scalable batch decompilation; MIDI availability for catalog items.
  • Bold: Version control and diffing for musical works — Sectors: software, creator tools
    • Description: Manage songs as text programs, enabling semantic diffs and PR-style reviews of arrangements.
    • Tools/workflows: Git integration; CI that compiles Strudel and exports audio previews; “musical diff” that highlights pattern/structure changes.
    • Assumptions/dependencies: Team workflows comfortable with code; mapping diffs to audible changes; storage of linked assets (soundfonts, instrument maps).
  • Bold: Compression and normalization of MIDI libraries — Sectors: content pipelines
    • Description: Replace verbose event streams with compact programmatic representations for storage and curation.
    • Tools/workflows: Batch “minify to Strudel” with reversible export to MIDI; deduplication via code similarity; canonicalization passes.
    • Assumptions/dependencies: Fidelity thresholds acceptable for archive use; deterministic round‑trip for specific clients.
  • Bold: Open-source baseline for execution-based RL on low-resource DSLs — Sectors: software/ML tooling
    • Description: Reuse the two-stage SFT+RL pipeline to adapt LLMs to other music DSLs (TidalCycles, Sonic Pi, SuperCollider syntax subsets).
    • Tools/workflows: Swap runtime and reward adapters; reuse GDPO setup; rubric customization per DSL.
    • Assumptions/dependencies: Headless, deterministic renderers; rubric design expertise; enough synthetic paired data for SFT warm-start.
  • Bold: IP triage and internal compliance checks — Sectors: media ops, legal ops
    • Description: Use decompiled structure to flag common patterns or potential derivative use in internal libraries before release.
    • Tools/workflows: Code-level motif fingerprinting; reports of high-overlap structural templates; human-in-the-loop review.
    • Assumptions/dependencies: Not a definitive legal determination; robust false-positive handling; policy alignment on acceptable similarity.

Long-Term Applications

These require further research, scaling, or ecosystem development to be production-ready.

  • Bold: Audio-to-code decompilation — Sectors: music tech, accessibility
    • Description: End-to-end system that transcribes audio to MIDI (AMT) and then to Strudel, including timbre, dynamics, and effects.
    • Tools/workflows: Integrate state-of-the-art AMT with instrument/timbre modeling and production-effect inference; multi-pass refinement with execution feedback.
    • Assumptions/dependencies: High-accuracy AMT across polyphonic, expressive recordings; models for effects chains; dataset coverage for acoustic attributes.
  • Bold: Long-form, section-aware decompilation — Sectors: music tech, academia
    • Description: Recover sectional form (intro–verse–chorus–bridge), thematic development, and recurrence over minutes-long works.
    • Tools/workflows: Hierarchical reward functions; memory-augmented models; program segmentation and “arrange” factories over long contexts.
    • Assumptions/dependencies: Larger datasets of long pieces with code ground truth or self-supervised signals; efficient long-context runtimes.
  • Bold: Cross-DSL interoperability standards — Sectors: standards, software
    • Description: A neutral, executable intermediate representation that compiles to/from Strudel, TidalCycles, Sonic Pi, and DAW formats.
    • Tools/workflows: Common schema and conformance tests; transpilers; “playback parity” test suites across engines.
    • Assumptions/dependencies: Community consensus; nuanced mapping of timing, swing, and humanization; open specification governance.
  • Bold: Creative-trace inference (program evolution) — Sectors: HCI, creator tools
    • Description: Infer a plausible sequence of REPL edits that builds the final piece, enabling tutorial generation and creativity analytics.
    • Tools/workflows: Inverse-planning over program edits; time-aligned reward shaping; interactive “show me how this was built” replays.
    • Assumptions/dependencies: Edit sequence identifiability; metrics for trace plausibility; datasets of live-coding sessions.
  • Bold: Rights management and licensing support — Sectors: policy, legal tech
    • Description: Use code-level motifs and harmonic templates to aid rights clearance, similarity assessment, and fair-use analysis.
    • Tools/workflows: Structural similarity indices; explainable reports highlighting shared code abstractions; thresholds co-designed with legal experts.
    • Assumptions/dependencies: Legal frameworks that recognize structural analyses; careful handling to avoid overreach; human adjudication.
  • Bold: Structure-aware recommendation and retrieval for streaming platforms — Sectors: media, recommender systems
    • Description: Recommend songs or stems based on code-level structure (groove, form, harmonic motion) rather than surface audio features alone.
    • Tools/workflows: Hybrid embeddings combining decompiled code tokens with audio features; playlist generators with form constraints.
    • Assumptions/dependencies: Scalable decompilation of large catalogs; bias and diversity safeguards; licensing for derivative analyses.
  • Bold: Assistive practice and pedagogy tools — Sectors: education, accessibility
    • Description: Personalized practice loops that refactor complex passages into simpler pattern code, auto-generate variations, and provide theory annotations.
    • Tools/workflows: Difficulty-aware refactoring; “explain this bar” code comments; adaptive exercises generated from decompiled segments.
    • Assumptions/dependencies: Accurate mapping between code refactors and cognitive difficulty; student modeling; device-friendly runtimes.
  • Bold: Data-centric ML for music structure understanding — Sectors: academia (ML/MIR)
    • Description: Train multimodal models to reason over compact programmatic representations jointly with audio and MIDI.
    • Tools/workflows: Pretraining corpora of (audio, MIDI, code) triplets; program-conditioned music QA; structure-aware captioning.
    • Assumptions/dependencies: Curated paired datasets; evaluation benchmarks for structure reasoning; robust code parsers.
  • Bold: Diversity-aware reward design for creative systems — Sectors: ML tooling, creator tech
    • Description: Extend reward to directly optimize for variety across samples while maintaining faithfulness/readability.
    • Tools/workflows: Diversity bonuses in GDPO; ensemble sampling; multi-objective Pareto front exploration for creators.
    • Assumptions/dependencies: Reliable diversity metrics that correlate with creative usefulness; avoidance of mode collapse.
  • Bold: Enterprise-grade pipelines for batch decompilation — Sectors: media ops, archives
    • Description: Process millions of MIDI/audio assets into code for archiving, search, and transformation at scale.
    • Tools/workflows: Distributed render farms for Strudel; fault-tolerant execution sandboxes; monitoring and quality dashboards.
    • Assumptions/dependencies: Cost-effective compute; strong observability; content governance and privacy controls.
  • Bold: Code-first generative music co-pilots — Sectors: creator tools, software
    • Description: Agents that suggest structural edits, regenerate sections under constraints, and verify results via execution-based feedback loops.
    • Tools/workflows: Plan–draft–execute–critique loops; in-IDE suggestions grounded by runtime renders; user-adjustable faithfulness/readability dials.
    • Assumptions/dependencies: Reliable online RL or retrieval-augmented inference; latency budgets for interactive use; safety filters for performance contexts.
  • Bold: Standardized evaluation and certifications for executable music tools — Sectors: policy, standards
    • Description: Certify tools on faithfulness, readability, and interoperability to reduce vendor lock-in and improve reliability.
    • Tools/workflows: Open test suites; certification badges; reporting requirements on runtime determinism.
    • Assumptions/dependencies: Multi-stakeholder participation (DAWs, live-coding communities, researchers); governance for updates as DSLs evolve.

Glossary

  • Algorithmic composition: The practice of generating music using formal rules and code. "Strudel is a domain-specific language (DSL) for algorithmic composition (Dean, 2018) and live coding (Collins et al., 2003; Wang & Cook, 2004) with JavaScript syntax."
  • Automatic music transcription: The task of converting audio into symbolic note events (e.g., MIDI), often used to evaluate faithfulness. "We adopt the instrument-aware onset metric from the multi-track automatic music transcription literature (Gardner et al., 2022; Lu et al., 2023; Chang et al., 2024; Mcleod & Steedman, 2018)"
  • Bipartite matching: A graph matching technique used to pair predicted and reference notes when computing evaluation scores. "The optimal pairing between reference and predicted notes is obtained by bipartite matching, and Rfaith is the resulting F1, computed with the standard mir_eval implementation (Raffel et al., 2014)."
  • Clipped group-relative policy objective: A reinforcement learning objective that clips advantages computed relative to a group of samples to stabilize training. "The final advantage is A(9) = > wKALg), which is used in the standard clipped group-relative policy objective to update Te."
  • CodeBLEU: A code-specific similarity metric extending BLEU with programming-language features. "Diversity is measured by the average pairwise CodeBLEU self-similarity (SelfCB; Ren et al., 2020) among compiled outputs from the same method."
  • Compile rate: The fraction of generated programs that successfully compile/execute. "For faithfulness, we report compile rate (Comp.) together with transcription metrics adapted from automatic music transcription"
  • Domain-specific language (DSL): A programming language tailored to a particular domain. "Strudel is a domain-specific language (DSL) for algorithmic composition (Dean, 2018) and live coding (Collins et al., 2003; Wang & Cook, 2004) with JavaScript syntax."
  • Execution-based reinforcement learning: RL where rewards are computed by executing generated programs and evaluating their outputs. "We propose DECOMPOSER, a two-stage post-training framework that combines supervised fine- tuning with execution-based reinforcement learning for symbolic music decompilation."
  • Execution feedback: Using the results of program execution as a learning signal for program synthesis/decompilation. "We approach symbolic music decompilation as program synthesis with execution feedback, following recent decompilation work that optimizes programs against a verifiable renderer"
  • Frame F1: A frame-level F1 score measuring agreement of note activity over time between reference and prediction. "For faithfulness, we report compile rate (Comp.) together with transcription metrics adapted from automatic music transcription (Gardner et al., 2022; Maman & Bermano, 2022; Chang et al., 2024): Onset F1, Frame F1, and Multi-Instrument Onset F1 (Inst F1)."
  • Frontier LLMs: The latest highly capable LLMs, typically closed-source. "frontier LLMs (OpenAI, 2026; Anthropic, 2026; Google DeepMind, 2026) often generate readable Strudel programs, but their rendered MIDI is not faithful to the input."
  • GDPO (Group reward-Decoupled normalization Policy Optimization): A GRPO-style RL algorithm that normalizes per-reward components across sampled groups before combining them. "To optimize Equation 3, we adopt Group reward-Decoupled normalization Policy Optimization (GDPO; Liu et al. 2026), a GRPO-style policy optimization method (Guo et al., 2025) for multi- reward objectives."
  • General MIDI program number: The standardized instrument identifier in the General MIDI specification. "is assigned the same General MIDI program number as the reference note."
  • GRPO: Group Relative Policy Optimization, an RL method using group-based relative advantages. "a GRPO- style policy optimization method (Guo et al., 2025)"
  • Instrument-aware onset metric: An onset-based evaluation metric that also accounts for instrument assignments. "We adopt the instrument-aware onset metric from the multi-track automatic music transcription literature"
  • List-wise LLM reranker: A ranking model that evaluates and orders multiple candidates jointly. "Readability is measured by the proposed rubric score (Rubric) and average rank from a list-wise LLM reranker (Rank; Tang et al., 2024)."
  • LoRA: A parameter-efficient fine-tuning method using low-rank adapters. "For SFT, we fine-tune each model for one epoch with LoRA (Hu et al., 2022)."
  • MIDI-to-Strudel decompilation: Converting symbolic MIDI into executable Strudel code that reproduces the input when run. "We instantiate the paradigm here through a MIDI-to-Strudel (Roos & McLean, 2023) task"
  • Mini-notation: A concise Strudel syntax (marked with )forexpressingmusicalpatterns."ThecodestyleseedScodeselectsamongdifferentprogramidiomsthatrealizethesamemusicaltarget,rangingfrommininotation() for expressing musical patterns. "The code-style seed Scode selects among different program idioms that realize the same musical target, ranging from mini-notation () based patterns to multi-section programs using arrange functions2."
  • mir_eval: A Python library for standard music information retrieval evaluation metrics. "computed with the standard mir_eval implementation (Raffel et al., 2014)."
  • Multi-Instrument Onset F1 (Inst F1): Onset F1 that matches notes only if pitch, timing, and instrument agree. "For faithfulness, we report compile rate (Comp.) together with transcription metrics ...: Onset F1, Frame F1, and Multi-Instrument Onset F1 (Inst F1)."
  • On-policy learning: RL training where the current policy generates the trajectories used for learning. "providing a warm start for on-policy learning."
  • Onset F1: An F1 score measuring correctness of note start times within a temporal tolerance. "For faithfulness, we report compile rate (Comp.) together with transcription metrics ...: Onset F1, Frame F1, and Multi-Instrument Onset F1 (Inst F1)."
  • Rubric-as-rewards: Using a checklist-style rubric, evaluated by an LLM, to derive reward signals for RL. "Following the rubric-as-rewards paradigm (Viswanathan et al., 2025; Gunjal et al., 2026), we therefore score readability with a fixed set of J = 12 rubric items"
  • Rubric score (Rubric): The aggregated readability score from binary rubric checks. "Readability is measured by the proposed rubric score (Rubric) and average rank from a list-wise LLM reranker"
  • SelfCB: The average pairwise CodeBLEU self-similarity among outputs from the same method. "Diversity is measured by the average pairwise CodeBLEU self-similarity (SelfCB; Ren et al., 2020) among compiled outputs from the same method."
  • STRUDEL-SYNTH: A synthetic paired dataset of Strudel programs and their rendered MIDI. "we additionally construct and release STRUDEL-SYNTH, a synthetic (MIDI, Strudel) corpus obtained by generating Strudel programs with a frontier LLM and rendering each program to MIDI."
  • Supervised fine-tuning (SFT): Training a model on paired examples with next-token prediction to initialize capabilities. "Stage 1: Supervised fine-tuning (SFT)."
  • Symbolic music decompilation: Recovering executable music-program code from symbolic music inputs. "We introduce symbolic music decompilation, the task of recovering executable, editable music- programming-language code from symbolic music input."
  • Unpaired MIDI: MIDI data without corresponding reference code, used for RL with execution-based rewards. "reinforcement learning on unpaired MIDI, optimizing rewards for both MIDI reconstruction faithfulness and code readability."

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 6 tweets with 74 likes about this paper.