238 lines
10 KiB
Markdown
238 lines
10 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.
|
|
|
|
## Acceptance Criteria
|
|
|
|
This sprint passes only if all of the following are true:
|
|
|
|
1. The live target is the already-open song.als session.
|
|
2. The run makes at least one real source-code change in the runtime or selection path, unless an already-existing code path is conclusively shown to be the canonical supported fallback and is validated end-to-end live.
|
|
3. At least one real Arrangement content edit is applied on the open project to improve harmonic continuity or fill a real weak span.
|
|
4. The backbone goal is met either by:
|
|
- meaningful Arrangement MIDI backbone content added live
|
|
- or a documented and validated supported fallback path that adds backbone-like Arrangement content when MIDI insertion is blocked
|
|
5. At least one coherence metric in the saved before/after evidence improves materially.
|
|
6. The run validates the previously missing live tool coverage:
|
|
- get_tracks()
|
|
- get_device_parameters(...)
|
|
- set_device_parameter_by_name(...)
|
|
7. Snare selectivity is validated through a real runtime path across at least two section contexts.
|
|
8. All changed Python files compile.
|
|
9. Relevant tests for touched code pass.
|
|
10. The validation report contains exact raw evidence references and does not overclaim.
|
|
11. Codex can reasonably return pass from repository evidence alone.
|
|
|
|
Automatic fail conditions:
|
|
- no source-code or real wiring change is made while blockers remain
|
|
- only property edits are applied again
|
|
- backbone remains absent and no validated fallback is delivered
|
|
- all saved coherence metrics remain flat again
|
|
- snare selectivity is still argued from inference instead of runtime evidence
|
|
- the report claims success without a measurable improvement
|
|
|
|
## 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
|
|
|
|
## Context
|
|
|
|
Read these first:
|
|
|
|
- previous run directory:
|
|
- C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue
|
|
- previous summary:
|
|
- C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\SUMMARY.md
|
|
- previous reviews:
|
|
- C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\codex_master_pre_fix.json
|
|
- C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\opencode_qwen3coder_plus.json
|
|
- C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\ralph\runs\20260403-203815-queue\reviews\opencode_glm47.json
|
|
- previous validation report:
|
|
- docs/SPRINT_v0.1.42_VALIDATION_REPORT.md
|
|
|
|
Most important evidence files from the previous run:
|
|
- temp/v04142_mcp_calls_final.jsonl
|
|
- temp/v04142_comprehensive_validation.json
|
|
- temp/v04142_audio_pattern_results.json
|
|
- temp/v04142_edit_actions.json
|
|
|
|
Primary source files:
|
|
- AbletonMCP_AI/MCP_Server/server.py
|
|
- abletonmcp_init.py
|
|
- AbletonMCP_AI/abletonmcp_runtime.py
|
|
- AbletonMCP_AI/MCP_Server/sample_selector.py
|
|
|
|
Execution priority for this sprint:
|
|
1. preserve the proven live connection and working arrangement-audio path
|
|
2. make the blocked backbone path succeed, or formalize a supported fallback in code
|
|
3. validate the previously missing live MCP tools
|
|
4. deliver one measurable coherence improvement
|
|
5. validate snare selectivity in a real runtime path
|
|
6. report only what repository evidence proves
|
|
|
|
Do not overclaim. The previous run proved that live editing is partially possible. This sprint exists to turn that partial proof into a repeatable, code-backed, measurable project improvement. |