173 lines
6.9 KiB
Markdown
173 lines
6.9 KiB
Markdown
# SPRINT v0.1.43 - Unlock Backbone Editing and Measurable Coherence Gains
|
||
|
||
## Goal
|
||
|
||
Use the live MCP connection on the already-open Ableton project:
|
||
|
||
- C:\Users\ren\Desktop\song Project\song.als
|
||
|
||
to close the remaining blocker from v0.1.42:
|
||
|
||
- convert the currently proven live inspection and audio-pattern editing path into a path that produces a meaningful harmonic backbone improvement and at least one measurable coherence improvement
|
||
|
||
This sprint is not about proving connectivity again in isolation.
|
||
|
||
This sprint is about:
|
||
- fixing or formalizing the blocked backbone-edit path
|
||
- using that path on the live project
|
||
- producing measurable before/after improvement
|
||
- validating snare selectivity in a real runtime path
|
||
|
||
## Why This Task Exists
|
||
|
||
Repository truth from v0.1.42:
|
||
|
||
- the run did reach the correct open project
|
||
- real MCP-driven Arrangement audio edits succeeded through `create_arrangement_audio_pattern`
|
||
- no source-code fix was made
|
||
- the harmonic MIDI backbone requirement was still not met
|
||
- key coherence metrics did not materially improve
|
||
- snare selectivity was still inferential rather than proven in a real selection path
|
||
|
||
High-signal truths from the run artifacts:
|
||
- `temp/v04142_mcp_calls_final.jsonl` proves `create_arrangement_audio_pattern` works live
|
||
- `temp/v04142_comprehensive_validation.json` shows 3 arrangement audio-pattern edits succeeded
|
||
- the same artifact shows mirrored pairs stayed at 100 and clip overuse stayed high
|
||
- `docs/SPRINT_v0.1.42_VALIDATION_REPORT.md` admits MIDI note insertion is still blocked
|
||
- the worktree had no source-code diff, so the blocker was diagnosed but not fixed
|
||
|
||
The next step is therefore not “more validation.â€
|
||
It is:
|
||
- implement the smallest real code fix or formal runtime fallback needed to make backbone extension and coherence improvement repeatable
|
||
- then prove it on song.als with exact metrics
|
||
|
||
## Required Work
|
||
|
||
1. Start from the live path that actually worked in v0.1.42.
|
||
- Reuse the live MCP connection approach that already validated the real open `song.als` session.
|
||
- Reuse the proven `create_arrangement_audio_pattern` path if MIDI editing remains blocked.
|
||
- Do not regress the working runtime path.
|
||
|
||
2. Resolve the backbone-edit blocker at code level.
|
||
- You must make a real code change in the runtime path this sprint unless the existing code already supports a better fallback and only wiring is missing.
|
||
- Priority order:
|
||
1. make a meaningful Arrangement MIDI backbone edit succeed
|
||
2. if that is genuinely blocked by the Live API, implement and validate a formal fallback path that creates backbone-like Arrangement content through a supported method
|
||
- A valid fallback is not random content.
|
||
- A valid fallback must:
|
||
- be intentional
|
||
- extend harmonic continuity
|
||
- be audibly useful
|
||
- be documented as the canonical path when MIDI insertion is blocked
|
||
|
||
3. Prove the fallback or fix is real on the live project.
|
||
- Apply at least one backbone-oriented Arrangement edit that increases continuity in a musically relevant span.
|
||
- The edit must target a real gap, weak span, or dead tail in song.als.
|
||
- The edit must not be only track property changes.
|
||
- It must be actual Arrangement content.
|
||
|
||
4. Require at least one measurable coherence improvement.
|
||
- Before editing, capture exact metrics.
|
||
- After editing, capture exact metrics again.
|
||
- At least one of these must improve in the saved evidence:
|
||
- silence islands
|
||
- mirrored section pairs
|
||
- harmonic coverage/backbone presence
|
||
- same-source dominance
|
||
- repeated clip overuse
|
||
- “3 patterns created†is not enough if the saved coherence metrics remain flat.
|
||
|
||
5. Validate the missing live MCP tools from v0.1.42.
|
||
- The previous run still under-validated the tool set.
|
||
- This sprint must exercise and record exact results for:
|
||
- get_tracks()
|
||
- get_device_parameters(...)
|
||
- set_device_parameter_by_name(...)
|
||
- Also re-confirm one arrangement creation/edit path and one audit path.
|
||
- If a tool is blocked, record the exact raw blocker and the exact fallback.
|
||
|
||
6. Validate snare selectivity in a real runtime path.
|
||
- Do not infer from the current project state.
|
||
- Do not cite older sprint text as proof.
|
||
- Run a real runtime path that exercises the selection logic or the relevant selection entry point.
|
||
- Record exact evidence showing whether the aggressive snare is penalized differently across at least two different section-energy contexts.
|
||
- If the scoring exists but is not wired into the runtime path, wire the minimum real path and validate it.
|
||
|
||
7. Keep scope tight and senior.
|
||
- Do not add broad new feature surfaces.
|
||
- Do not rewrite the generation system.
|
||
- Touch only the files required to:
|
||
- unlock the blocked edit path
|
||
- validate the missing tool coverage
|
||
- make the coherence improvement measurable
|
||
- Likely candidates:
|
||
- AbletonMCP_AI/MCP_Server/server.py
|
||
- abletonmcp_init.py
|
||
- AbletonMCP_AI/abletonmcp_runtime.py
|
||
- AbletonMCP_AI/MCP_Server/sample_selector.py
|
||
- docs/SPRINT_v0.1.43_VALIDATION_REPORT.md
|
||
|
||
8. Fail honestly if the blocker is fundamental and unfixed.
|
||
- If the MIDI path remains fundamentally blocked, the report must say so explicitly.
|
||
- But in that case the sprint still must either:
|
||
- ship a real validated fallback path with measurable improvement
|
||
- or fail
|
||
- A documentation-only explanation is not enough anymore.
|
||
|
||
## Validation
|
||
|
||
Produce all of the following artifacts:
|
||
|
||
1. docs/SPRINT_v0.1.43_VALIDATION_REPORT.md
|
||
Required sections:
|
||
- Summary
|
||
- Files Changed
|
||
- Live Target Proof
|
||
- Runtime Fix or Canonical Fallback
|
||
- MCP Tools Validated Live
|
||
- Project Audits Before
|
||
- Project Edits Applied
|
||
- Project Audits After
|
||
- Before/After Metrics
|
||
- Snare Selectivity
|
||
- Harmonic Backbone Outcome
|
||
- What Is Still Weak
|
||
- Remaining Risks
|
||
|
||
2. temp/v04143_live_target_proof.json
|
||
- raw proof that the active session is the intended open project
|
||
|
||
3. temp/v04143_mcp_calls.jsonl
|
||
- one JSON line per MCP call
|
||
- include tool name, arguments, success/failure, and raw result/error
|
||
|
||
4. temp/v04143_before_audit.json
|
||
- raw before-state audit outputs
|
||
|
||
5. temp/v04143_after_audit.json
|
||
- raw after-state audit outputs
|
||
|
||
6. temp/v04143_edit_actions.json
|
||
- exact live edits attempted and whether each succeeded
|
||
|
||
7. temp/v04143_snare_selectivity_validation.json
|
||
- runtime evidence for at least two section contexts
|
||
- include the exact sample candidates or scoring evidence used
|
||
|
||
8. temp/v04143_blocker_or_fallback.json
|
||
- if MIDI remains blocked, document:
|
||
- exact failing call
|
||
- exact raw response
|
||
- exact supported fallback used instead
|
||
- proof that the fallback was applied live
|
||
|
||
9. temp/v04143_metric_delta.json
|
||
- explicit before/after delta summary for the coherence metrics
|
||
|
||
Required validation actions:
|
||
- python -m py_compile on every changed Python file
|
||
- relevant tests for every touched runtime/MCP/selection file
|
||
- live MCP calls against the open project
|
||
- before and after audits from the same live session
|
||
- exact evidence for either a fixed backbone path or a validated fallback path
|