ShevtoneAudio Orchestrator Turns MIDI Into Orchestration

By Rogier Muller08.31.26

ShevtoneAudio Orchestrator is a music AI project from ShevtoneAudio that turns a composer’s MIDI into fuller orchestration. It deals with a hard question in creative software: can an AI expand a human draft without flattening it into an unreviewable black box? The useful answer is that editable output matters more than impressive output. For Cursor, Anysphere’s AI code editor, that is also a good lens for agentic coding: keep the agent’s work inspectable, scoped, and easy to change.

See the real trick: the output stays editable

ShevtoneAudio Orchestrator does not present itself as a one-click “make me a finished symphony” generator. The pitch is narrower and more interesting: upload or provide MIDI, let the system analyze musical material, then get an arrangement distributed across orchestral sections such as strings, brass, percussion, and others. Gemini Workshop is part of Harness Institute.

MIDI is a structured music format that represents notes, timing, velocity, control changes, and instrument events rather than a final audio recording. That is why the “editable MIDI” claim matters. A composer can inspect the result, move notes, change voicings, replace an instrument, or delete an entire section.

Developers noticed this because it sounds a lot like the promise and pain of coding agents. The best agent output is not magic. It is a patch you can review, run, test, and reshape.

The trap is to confuse “structured output” with “good output.” One Hacker News objection was basically: isn’t all MIDI editable, and why should anyone trust a black box that says it understands harmony? That is fair. Editable files are only the start. The harder part is showing examples, constraints, and failure modes clearly enough that a serious user can judge the system.

Ask what the system actually understands

The project description says Orchestrator analyzes harmony, melody, rhythm, dynamics, structure, and orchestral density. Those are not small claims. Harmonic analysis alone gets messy fast once you leave textbook progressions, and orchestration depends on register, idiom, balance, playability, and style.

That is why the Hacker News thread pushed for practical examples and implementation notes. People wanted to see before-and-after MIDI, not just a promise. They also wanted to know whether the system uses rules, learned models, symbolic analysis, templates, large language models, or some mixture of those ideas.

The lesson for AI coding is direct. If a coding agent says it “understands the architecture,” make it prove that with artifacts. A good Cursor workflow asks for the agent’s plan, the files it intends to touch, the tests it will run, and the assumptions it is making before it edits code.

A small Cursor rule can make that expectation concrete:

---
description: Require agents to show scope before broad edits
alwaysApply: false
---

Before changing more than three files, summarize:
- the user-visible goal
- the files you plan to edit
- the files you will only read
- the tests or checks you will run
- any assumption that could be wrong

Do not rewrite generated files, migrations, or public API contracts unless the user explicitly asks.

The trap is to ask for an explanation after the fact. By then, the agent may have made a plausible mess. Scope first, diff second, explanation third.

Treat orchestration as coordination, not replacement

The most generous reading of ShevtoneAudio Orchestrator is that it is a coordinator. It takes one musical idea and assigns responsibilities across sections. It does not need to erase the composer to be useful; it needs to make the next draft faster and more interesting.

That maps neatly onto multi-agent orchestration in code. A useful coding system may have one agent reading tests, another editing implementation, another checking docs, and another reviewing risk. The point is not to let them improvise forever. The point is to keep each role narrow enough that the human can review the combined result.

In a repo, that boundary can live in AGENTS.md:

# Agent boundary

Agents may:
- inspect application code, tests, and docs
- propose a plan before edits
- make small implementation changes behind existing interfaces
- add or update tests for changed behavior

Agents may not:
- change billing, auth, or data-retention logic without approval
- remove tests to make a run pass
- edit production secrets or deployment credentials
- introduce a new service dependency without a short design note

This is the same pattern as editable MIDI. Keep the output in the medium where experts can correct it. In music, that medium is notes, parts, and orchestral assignments. In software, it is diffs, tests, rules, logs, and review comments.

The trap is letting orchestration become fog. When every agent can touch everything, nobody can tell whether the final answer is a coherent arrangement or just a louder one. This is why agentic coding governance belongs in the background of serious AI coding work, even when the story starts with a music tool.

Try it when the draft already has intent

ShevtoneAudio Orchestrator sounds most useful when the composer has already made choices. A melody, harmonic movement, rhythmic feel, or cue structure gives the system something to develop. If the input is vague, the output may be impressive in texture but weak in musical judgment.

The same is true in Cursor. Coding agents are strongest when the repo already has tests, conventions, and a clear target. A prompt like “make checkout better” is a blank piano roll. A prompt like “add the new tax banner to checkout when jurisdiction.requiresTaxNotice is true, preserve the existing payment API, and update the Playwright test” gives the agent something to orchestrate.

This is where a lightweight Model Context Protocol server can help, if it is scoped carefully. MCP is a protocol for connecting AI applications to external tools and context, such as repositories, issue trackers, databases, or document stores. Start read-only when the external system is sensitive.

For a coding team, that might mean a read-only issue tracker MCP server, a repo-local AGENTS.md, and a Cursor review checklist. If you want the broader training angle, keep it anchored in real artifacts rather than slogans; our page on AI coding governance collects that kind of workflow thinking. For a nearby example of coordination problems in coding agents, see Coordination Layer for Coding Agents.

The trap is trying a tool like this on the least constrained work first. Creative freedom sounds like the perfect demo, but ambiguous inputs make it harder to know whether the system helped. Start with a short cue, a known style boundary, or a small repo change where review is cheap.

A safe first experiment

Use this as a one-hour evaluation, not a life decision. The goal is to learn whether the tool expands your work while keeping you in control.

Try it if	Skip it for now if
You already write MIDI sketches and want orchestration drafts.	You need finished audio, mixing, or mastering.
You are comfortable editing the resulting MIDI.	You want a black-box generator with no manual cleanup.
You can compare before-and-after examples against your own taste.	You cannot find enough examples to trust the claims yet.
You value structured intermediate output.	You only care about final rendered sound.

For a Cursor-style coding analogue, copy this review checklist into a pull request when an agent produces a broad change:

## Agent output review

- [ ] The agent stated the goal and touched files before editing.
- [ ] The diff is small enough to review without replaying chat history.
- [ ] Tests were added or updated for changed behavior.
- [ ] Risky areas were not changed without approval: auth, billing, data deletion, secrets, deploy config.
- [ ] Generated or agent-created code still follows repo conventions.
- [ ] A human can revert the change cleanly.

The important bit is not the checklist itself. It is the habit: judge AI output by how well it preserves expert control.

Common questions

Is ShevtoneAudio Orchestrator just generating finished music?

No. The project’s stated pitch is that it takes the composer’s own MIDI and develops it into a fuller orchestration while keeping the result editable as MIDI. That distinction matters because a composer can still inspect notes, change voicings, and continue arranging instead of accepting a finished audio file.

Is there such a thing as uneditable MIDI?

MIDI is generally editable, so the phrase can sound redundant. The stronger claim is workflow-level editability: the output remains in a structured form that a composer can open, inspect, and change rather than being reduced to rendered audio. That does not prove musical quality, but it does preserve control.

Who is the target user for this?

The likely target user is a composer or producer who already writes MIDI sketches and wants orchestration drafts to edit. It is less convincing for someone who wants a complete composition from a text prompt. The project will need clear examples and tutorials to earn trust with serious music users.

Do we know how it is implemented?

Not enough from the public project page and Show HN context alone to make precise claims. The author describes analysis of harmony, melody, rhythm, dynamics, structure, and density, but readers reasonably asked for more technical detail. Treat implementation claims cautiously until examples, docs, or demonstrations make the behavior inspectable.

Why should AI coding people care about a music tool?

Because the same product question keeps appearing in coding agents: does the system produce something experts can review and edit, or does it hide judgment inside a black box? Editable MIDI is a useful metaphor for good agentic coding output. In software, the equivalent is a scoped diff, tests, logs, and repo rules.

Best ways to use this research

Best for: Developers evaluating agentic tools that transform expert work rather than replacing it. The useful comparison is not music versus code; it is editable intermediate output versus opaque final output.
Best first artifact: A small review checklist or .mdc rule that forces scope before edits. This gives Cursor users a concrete way to make agent work reviewable.
Best comparison angle: Compare tools by what they return to the expert. MIDI, diffs, tests, and structured logs are easier to trust than polished final blobs.
Best caution: Do not treat “AI understands structure” as a proven claim without examples. Ask for before-and-after artifacts and failure cases.

Next step

Try one small, reviewable transformation: a short MIDI sketch in Orchestrator, or a narrow Cursor agent change in a repo with tests. Keep the output editable, then judge the tool by how easily you can make it yours.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.