164 lines
6.2 KiB
Markdown
164 lines
6.2 KiB
Markdown
# SPRINT v0.1.42 - Live Proof of Open-Project Editing
|
|
|
|
## Goal
|
|
|
|
Validate and use the existing MCP editing path on the already-open Ableton project:
|
|
|
|
- C:\Users\ren\Desktop\song Project\song.als
|
|
|
|
This sprint is not a generation sprint and not a wrapper-expansion sprint.
|
|
|
|
It is a runtime-proof sprint:
|
|
|
|
- prove the MCP can inspect the real open project
|
|
- prove the MCP can apply real Arrangement edits on that project
|
|
- prove the edits improve coherence in measurable ways
|
|
- document exact evidence or fail explicitly
|
|
|
|
## Why This Task Exists
|
|
|
|
The previous run failed.
|
|
|
|
Repository truth from the failed run:
|
|
|
|
- infrastructure was added in AbletonMCP_AI/MCP_Server/server.py
|
|
- contextual snare scoring was added in AbletonMCP_AI/MCP_Server/sample_selector.py
|
|
- docs/SPRINT_v0.1.41_VALIDATION_REPORT.md was corrected to an honest fail
|
|
- no live MCP calls were exercised against song.als
|
|
- no real edit pass was applied
|
|
- no before/after coherence metrics were captured
|
|
- no proof exists that the new editing tools work through the real Ableton runtime path
|
|
|
|
The highest-signal blocker is now obvious:
|
|
|
|
- stop adding unvalidated infrastructure
|
|
- prove runtime behavior on the open project
|
|
- if runtime behavior is blocked, isolate the exact blocker with raw evidence
|
|
|
|
## Required Work
|
|
|
|
1. Prove the live target is the real open project.
|
|
- Connect through the MCP to the active Ableton session.
|
|
- Capture enough session evidence to prove the target is the already-open song.als session and not a generated set or blank template.
|
|
- Save raw outputs under temp/.
|
|
|
|
2. Validate the existing MCP tool path live before adding more tools.
|
|
- Exercise these tools against the open project and record exact calls plus raw outputs:
|
|
- get_session_info()
|
|
- get_tracks()
|
|
- get_track_info(...)
|
|
- get_clips(...)
|
|
- get_clip_info(...)
|
|
- get_devices(...)
|
|
- get_device_parameters(...)
|
|
- set_device_parameter_by_name(...)
|
|
- one arrangement creation or duplication path
|
|
- one arrangement MIDI note insertion path
|
|
- For each tool, classify it as:
|
|
- live validated
|
|
- failed live
|
|
- blocked by backend/runtime limitation
|
|
- Do not mark a tool complete just because it compiles.
|
|
|
|
3. If a live tool path fails, fix only the minimal blocker.
|
|
- Use the existing code added in v0.1.41 as the starting point.
|
|
- If a backend handler or runtime path is missing, add the smallest fix needed in the real runtime path.
|
|
- Re-run the exact same MCP call after the fix and save the before/after evidence.
|
|
- Do not add unrelated new feature surface.
|
|
|
|
4. Audit the open project before editing.
|
|
- Run project-facing audits on the real song.als session.
|
|
- Capture exact before metrics for:
|
|
- silence islands
|
|
- mirrored section pairs
|
|
- harmonic coverage / harmonic backbone status
|
|
- same-source dominance or repeated-source overuse
|
|
- repeated clip overuse if available
|
|
- Save raw outputs under temp/.
|
|
- Use these audits to choose the edit targets.
|
|
|
|
5. Apply a bounded real edit pass on song.als.
|
|
- Use the validated MCP editing tools on the real open project.
|
|
- The edit pass must be small, targeted, and measurable.
|
|
- Prioritize:
|
|
- extending or repairing harmonic MIDI backbone in Arrangement
|
|
- reducing dead gaps
|
|
- breaking at least one mirrored or obviously repeated arrangement shape
|
|
- improving continuity without destroying identity
|
|
- The harmonic MIDI backbone must become real Arrangement content intended to be audible.
|
|
- It is acceptable to use keys, pluck, pad, or synth timbre.
|
|
- It is not acceptable to leave the backbone as metadata, a hidden clip, or an empty placeholder.
|
|
|
|
6. Validate snare selectivity in the real path.
|
|
- Do not hard-ban SS_RNBL_Me_Gustas_One_Shot_Snare.wav.
|
|
- Prove whether the new contextual snare scoring actually affects selection in real use.
|
|
- If the logic exists but is not wired into the live path, wire the minimal real path and validate it.
|
|
- Record exact evidence showing whether lower-energy sections are treated more conservatively than higher-energy sections.
|
|
|
|
7. Re-audit after editing.
|
|
- Run the same project-facing audits again.
|
|
- Save raw after-state outputs under temp/.
|
|
- Produce an exact before/after table using measured values, not estimates.
|
|
- State clearly what improved, what stayed flat, and what regressed.
|
|
|
|
8. Keep the scope disciplined.
|
|
- Touch only the files directly required to validate or minimally fix the runtime editing path.
|
|
- Likely files:
|
|
- AbletonMCP_AI/MCP_Server/server.py
|
|
- AbletonMCP_AI/MCP_Server/sample_selector.py
|
|
- abletonmcp_init.py
|
|
- AbletonMCP_AI/abletonmcp_runtime.py
|
|
- docs/SPRINT_v0.1.42_VALIDATION_REPORT.md
|
|
- Do not add broad new capability areas unless they are the direct blocker to a required live validation step.
|
|
|
|
9. Fail fast if the runtime is not reachable.
|
|
- If Ableton, the control surface, or the MCP connection is unavailable, do not continue building infrastructure.
|
|
- Capture the exact failing step and raw evidence.
|
|
- Mark the sprint failed with specific blocker evidence.
|
|
- A code-only partial success is not acceptable for this sprint.
|
|
|
|
## Validation
|
|
|
|
Produce all of the following artifacts:
|
|
|
|
1. docs/SPRINT_v0.1.42_VALIDATION_REPORT.md
|
|
Required sections:
|
|
- Summary
|
|
- Files Changed
|
|
- Live Target Proof
|
|
- MCP Tools Validated Live
|
|
- Project Audits Before
|
|
- Project Edits Applied
|
|
- Project Audits After
|
|
- Before/After Metrics
|
|
- Snare Selectivity
|
|
- Harmonic MIDI Backbone
|
|
- What Is Still Weak
|
|
- Remaining Risks
|
|
|
|
2. temp/v04142_live_target_proof.json
|
|
- raw evidence proving the active Ableton session is the intended open project
|
|
|
|
3. temp/v04142_mcp_calls.jsonl
|
|
- one JSON line per MCP call
|
|
- include tool name, arguments, success or failure, and raw result or raw error
|
|
|
|
4. temp/v04142_before_audit.json
|
|
- raw before-state audit outputs
|
|
|
|
5. temp/v04142_after_audit.json
|
|
- raw after-state audit outputs
|
|
|
|
6. temp/v04142_edit_actions.json
|
|
- exact live edits attempted and whether each succeeded
|
|
|
|
7. If blocked, replace missing success artifacts with:
|
|
- temp/v04142_blocker_evidence.json
|
|
- include the exact failing step, exact raw response, and why the sprint could not proceed
|
|
|
|
Required validation actions:
|
|
- python -m py_compile on every changed Python file
|
|
- relevant tests for touched runtime/MCP/coherence code
|
|
- live MCP calls against the open project
|
|
- before and after audits on the same open project session
|