Decomposer: Learning to Decompile Symbolic Music to Programs
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.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
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-SYNTHis 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
Strudelis 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
MidiToTextrepresentation 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.
- The
- 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 ) 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."
Collections
Sign up for free to add this paper to one or more collections.