ableton-mcp-ai/docs/SPRINT_v0.1.43_NEXT_GLM_MANUAL_OPEN_PROJECT_EDITING.md

SPRINT v0.1.43 - GLM Manual Open Project Editing

Audience

GLM via OpenCode, with manual review by Codex after implementation.

Context

Before coding, read:

1. C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AGENTS.md
2. C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\CLAUDE.md
3. C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\PROJECT_AUDIT_song_2026-04-03.md
4. this sprint file

Do not rely on old "completed" reports without checking current code and the current open set.

Working Mode

• This sprint is manual, not autopilot.
• Work against the currently open project C:\Users\ren\Desktop\song Project\song.als.
• Do not generate a brand-new song.
• Use MCP live evidence and code changes together.

Why This Sprint Exists

The repo guidance was too generic and the implementation flow drifted into:

• overly symmetrical arrangements
• too many silent gaps
• weak harmonic continuity
• reports that overstated closure
• confusion between "harmonic MIDI" and "must sound like a piano"

That guidance has now been rewritten in AGENTS.md, CLAUDE.md, .cursorrules, and .github/copilot-instructions.md. Use those files as the repo contract for this sprint.

Product Direction

The target sound should feel:

• coherent
• editable
• less empty
• less mirrored
• more musically continuous
• freer in sound selection without becoming random

Important:

• harmonic MIDI is desired
• forced piano timbre is not desired
• automatic vocals are not desired

Code Review Findings You Must Respect

1. The project currently overuses short repeated blocks and visible mirror symmetry.
2. Harmonic support often exists in theory but not enough in Arrangement.
3. Silent gaps are still too common and too large.
4. Some agents overfit to manifests and under-validate the actual open set.
5. The open-project editing path is more important than another generation path.

Goals

G1. Improve open-project editing tools

Strengthen MCP editing for already-open projects. Prioritize real inspection and mutation tools that help continue song.als.

G2. Improve coherence and continuity

Reduce structural holes and increase harmonic continuity across the arrangement.

G3. Restore sound-selection freedom without losing coherence

The system should not always choose the same tiny set of sounds, but the result should still feel like one song.

Required Coding Work

T1. Inspect and harden open-project editing tools

Review and improve the tools used for:

• track inspection
• clip inspection
• device parameter inspection
• arrangement clip editing
• harmonic repair or continuity repair

If a tool is only analysis_only, say so explicitly in code and report. Do not market it as full editing.

T2. Reduce silence-driven "variation"

Any logic that creates variation primarily by removing content and leaving empty space should be reduced or made more selective.

Variation should come more from:

• section-aware substitutions
• clip continuity edits
• density changes that keep a backbone alive
• harmonic support that survives transitions

T3. Keep harmonic MIDI alive across the song

If the project has a harmonic MIDI backbone, it should help fill structural holes across the arrangement.

This does not mean "make it sound like a piano." It means the harmonic lane should exist, be editable, and support the song over time.

T4. Make sound choice slightly freer but still coherent

Relax over-rigid sameness where it causes "the same 3 sounds forever."

But do this with coherence-aware logic:

• family compatibility
• pack compatibility
• section role
• continuity of musical identity

Do not replace one rigid system with random selection.

Validation Requirements

You must validate on the open project, not only in tests.

Required runtime evidence

• exact MCP calls used
• before/after project audit
• proof of the edited target tracks, clips, or devices
• proof that the open project remained stable

Required code validation

• py_compile on every changed Python file
• targeted tests relevant to the touched area

Minimum report contents

Your report must include:

• files changed
• exact MCP calls issued
• before/after evidence for coherence or continuity
• what is still partial or not yet proven
• what remains manual-only

Hard Failure Conditions

The sprint is not complete if any of these are true:

• you only improved docs and not the tool path
• you used a generated set instead of the open project
• you claimed harmonic improvement without proving Arrangement-level evidence
• you introduced more empty space while claiming better variation
• you conflated harmonic MIDI with mandatory piano timbre
• you gave only manifest evidence and not MCP or live evidence

Deliverables

1. code changes
2. docs/SPRINT_v0.1.43_VALIDATION_REPORT.md
3. runtime artifacts in temp/ if needed
4. a concise section listing what still is not fully solved

Final Reminder

The bar is not "the tool exists." The bar is "the open project became easier to continue, less empty, and more coherent without becoming rigid or generic."