Sync: Complete project state with all MEGA SPRINT V1-V3 features and Codex stubs
This commit is contained in:
renato97
316
docs/SPRINT_v0.1.41_NEXT_RALPH_OPEN_PROJECT_EDITING.md
Normal file
316
docs/SPRINT_v0.1.41_NEXT_RALPH_OPEN_PROJECT_EDITING.md
Normal file
@@ -0,0 +1,316 @@
|
||||
# SPRINT v0.1.41 - Ralph Swarm - Open Project Editing and Coherence
|
||||
|
||||
## Goal
|
||||
|
||||
Use the Ralph swarm to work on the already-open Ableton project:
|
||||
|
||||
- `C:\Users\ren\Desktop\song Project\song.als`
|
||||
|
||||
This is not a new-song generation sprint.
|
||||
|
||||
This sprint is about:
|
||||
|
||||
1. giving the MCP more real editing power over open projects
|
||||
2. using those tools on the current open project
|
||||
3. improving coherence, continuity and musical identity
|
||||
4. reducing symmetry, repeated blocks and empty gaps
|
||||
5. treating harmonic MIDI as a real backbone across the full arrangement
|
||||
|
||||
## Important Product Clarification
|
||||
|
||||
The user comes from FL Studio and may say `piano roll`.
|
||||
|
||||
In this project that means:
|
||||
|
||||
- harmonic MIDI backbone
|
||||
- long-form arrangement MIDI that carries harmony/melodic identity
|
||||
- editable MIDI clips in Arrangement
|
||||
|
||||
It does **not** mean:
|
||||
|
||||
- force piano timbre everywhere
|
||||
- spam piano loops
|
||||
- replace the user library with generic piano sounds
|
||||
|
||||
The right interpretation is:
|
||||
|
||||
- use `HARMONY_*_MIDI` as the musical spine
|
||||
- blend that spine with the user's library
|
||||
- keep the project library-first-hybrid
|
||||
- make the MIDI audible, useful and persistent throughout the song
|
||||
|
||||
## Current Problems To Solve
|
||||
|
||||
The current system has improved, but the open-project result still tends to show:
|
||||
|
||||
- too much geometric symmetry
|
||||
- repeated section shapes with near-identical spacing
|
||||
- too many silence islands
|
||||
- a good 4-second loop followed by dead air
|
||||
- harmonic MIDI backbone still too weak or too local
|
||||
- sections differentiated by removal instead of transformation
|
||||
- sound selection still too conservative or too repetitive
|
||||
- aggressive snares sometimes damaging coherence
|
||||
|
||||
The specific snare to watch carefully is:
|
||||
|
||||
- `SS_RNBL_Me_Gustas_One_Shot_Snare.wav`
|
||||
|
||||
Do **not** hard-ban it blindly.
|
||||
|
||||
Instead:
|
||||
|
||||
- analyze when it is appropriate
|
||||
- score it more selectively by section energy, density and surrounding sources
|
||||
- stop it from dominating softer sections or smoother grooves
|
||||
|
||||
## Scope
|
||||
|
||||
This sprint has two parallel tracks that must meet in one validated result.
|
||||
|
||||
### Track A - MCP Capability
|
||||
|
||||
Strengthen the public MCP editing workflow for an already-open project.
|
||||
|
||||
The target is not theoretical wrappers.
|
||||
|
||||
The target is:
|
||||
|
||||
- inspect open project
|
||||
- inspect clips/devices/parameters
|
||||
- edit Arrangement
|
||||
- edit MIDI in Arrangement
|
||||
- edit device parameters by name
|
||||
- use repair tools meaningfully on a real project
|
||||
|
||||
### Track B - Project Editing
|
||||
|
||||
Apply those tools to `song.als` and improve the real set.
|
||||
|
||||
Do not stop at “tools exist”.
|
||||
|
||||
Use them.
|
||||
|
||||
## Required Outcomes
|
||||
|
||||
### A. Open-project editing must be real
|
||||
|
||||
At least these MCP abilities must be validated live on the open project:
|
||||
|
||||
- inspect tracks
|
||||
- inspect clips on a track
|
||||
- inspect a specific clip
|
||||
- inspect devices on a track
|
||||
- inspect device parameters
|
||||
- set a device parameter by name
|
||||
- create or duplicate Arrangement material
|
||||
- add MIDI notes in Arrangement
|
||||
- retrieve enough project state to support editing decisions
|
||||
|
||||
If any of these are still analysis-only or fallback-only, say so explicitly.
|
||||
|
||||
Do not mark them complete unless they were exercised against the open Live project.
|
||||
|
||||
### B. Harmonic MIDI backbone must become real arrangement content
|
||||
|
||||
The harmonic MIDI backbone must:
|
||||
|
||||
- exist in Arrangement, not just Session
|
||||
- span much more of the song, not only one local region
|
||||
- be audible and useful for continuity
|
||||
- help fill gaps where the arrangement currently drops out
|
||||
- support the user library rather than replacing it
|
||||
|
||||
It is acceptable if the timbre is pluck/keys/pad/synth instead of literal piano.
|
||||
|
||||
It is not acceptable if the MIDI exists only as metadata or one hidden clip.
|
||||
|
||||
### C. Coherence must improve without becoming sterile
|
||||
|
||||
The edit pass must reduce:
|
||||
|
||||
- mirrored section pairs
|
||||
- dead gaps between phrases
|
||||
- silence islands
|
||||
- same-source overuse
|
||||
- section-to-section copy-paste feel
|
||||
|
||||
At the same time, it must preserve:
|
||||
|
||||
- clear structure
|
||||
- strong recognizable motif
|
||||
- coherent sound family choices
|
||||
- continuity across drums, bass and harmony
|
||||
|
||||
Do not solve “repetition” by randomizing everything.
|
||||
Do not solve “coherence” by making every section identical.
|
||||
|
||||
### D. Sound freedom with discipline
|
||||
|
||||
The system should gain a bit more freedom in sound choice, but inside a coherent frame.
|
||||
|
||||
That means:
|
||||
|
||||
- allow controlled variation of support layers
|
||||
- allow section-aware alternates
|
||||
- keep identity layers constrained
|
||||
- avoid collapsing everything into 3-4 sounds
|
||||
- avoid hard lock to one exact symmetric loop
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
The sprint is complete only if all of these are true:
|
||||
|
||||
1. the open project `song.als` was used as the validation target
|
||||
2. MCP editing tools were validated live, not just compiled
|
||||
3. the open project received a real edit pass
|
||||
4. harmonic MIDI backbone exists in Arrangement and covers materially more of the song
|
||||
5. silence islands and mirrored symmetry were measured before and after
|
||||
6. the result is less empty and less repetitive without losing structure
|
||||
7. sound selection logic for aggressive snares became more selective instead of a blind blacklist
|
||||
8. all changed Python files compile
|
||||
9. relevant tests pass
|
||||
10. the report includes exact MCP calls used on the open project
|
||||
11. the report includes exact before/after coherence metrics
|
||||
12. Codex final verdict is `pass`
|
||||
|
||||
## Mandatory Validation
|
||||
|
||||
Validation must include all of the following:
|
||||
|
||||
### 1. Code validation
|
||||
|
||||
- `python -m py_compile` on every changed Python file
|
||||
- relevant tests for MCP/runtime/coherence
|
||||
|
||||
### 2. Live validation
|
||||
|
||||
Against the open Ableton project:
|
||||
|
||||
- `get_session_info()`
|
||||
- `get_tracks()`
|
||||
- `get_track_info(...)`
|
||||
- the editing tools exercised for real
|
||||
|
||||
### 3. Project audit
|
||||
|
||||
Run project-facing audits before and after the edit pass, including:
|
||||
|
||||
- silence islands
|
||||
- mirrored section pairs
|
||||
- harmonic coverage / backbone status
|
||||
- same-source dominance or reuse
|
||||
- repeated clip overuse if available
|
||||
|
||||
### 4. Audible sanity
|
||||
|
||||
The report must state clearly:
|
||||
|
||||
- whether the harmonic MIDI is actually audible
|
||||
- whether gaps were reduced
|
||||
- whether the project still feels too symmetric
|
||||
- whether the snare selectivity improved
|
||||
|
||||
## Constraints
|
||||
|
||||
- Do not generate a new song from scratch.
|
||||
- Do not replace the project with a fresh template.
|
||||
- Do not rely on Session-only material and then claim Arrangement success.
|
||||
- Do not treat wrappers or helper functions as success.
|
||||
- Do not add vocals.
|
||||
- Do not force literal piano timbre just because the user said “piano roll”.
|
||||
- Do not hard-ban `SS_RNBL_Me_Gustas_One_Shot_Snare.wav`; score it contextually.
|
||||
- Do not overclaim if the edit tools still depend on fragile transport hacks.
|
||||
- Do not mark complete if the live project still looks obviously symmetrical and full of dead gaps.
|
||||
|
||||
## Implementation Guidance
|
||||
|
||||
### For MCP capability work
|
||||
|
||||
Prioritize tools that matter for editing open projects:
|
||||
|
||||
- clip inspection
|
||||
- device inspection
|
||||
- parameter editing by name
|
||||
- Arrangement MIDI editing
|
||||
- duplication and continuity repair
|
||||
- project audit tools that reflect real editing pain
|
||||
|
||||
If a tool remains inherently limited by the Live API, document the exact limit and the exact fallback.
|
||||
|
||||
### For project editing work
|
||||
|
||||
Use the project audit as the source of truth.
|
||||
|
||||
Then make targeted edits:
|
||||
|
||||
- extend harmonic continuity
|
||||
- reduce dead air
|
||||
- break mirrored copy-paste shapes
|
||||
- vary support layers across sections without losing family identity
|
||||
- tighten selection of snare/clap layers by context
|
||||
|
||||
Preferred musical strategy:
|
||||
|
||||
- strong recurring identity
|
||||
- long-form harmonic support
|
||||
- fewer abrupt disappearances
|
||||
- section evolution by mutation, layering and phrasing
|
||||
- support layers changing more than core identity layers
|
||||
|
||||
## Required Deliverables
|
||||
|
||||
The implementing swarm must produce:
|
||||
|
||||
1. code changes
|
||||
2. a validation report:
|
||||
- `docs/SPRINT_v0.1.41_VALIDATION_REPORT.md`
|
||||
3. if needed, one or more exported JSON artifacts under `temp/`
|
||||
4. explicit list of changed files
|
||||
5. exact MCP calls used
|
||||
6. before/after metric table
|
||||
7. a short section titled `Remaining Risks`
|
||||
|
||||
## Report Format
|
||||
|
||||
The validation report must contain these sections:
|
||||
|
||||
1. `Summary`
|
||||
2. `Files Changed`
|
||||
3. `MCP Tools Validated Live`
|
||||
4. `Project Edits Applied`
|
||||
5. `Before/After Metrics`
|
||||
6. `Snare Selectivity`
|
||||
7. `Harmonic MIDI Backbone`
|
||||
8. `What Is Still Weak`
|
||||
9. `Remaining Risks`
|
||||
|
||||
## Failure Conditions
|
||||
|
||||
The sprint automatically fails if any of these happen:
|
||||
|
||||
- the work validates against a new generated song instead of `song.als`
|
||||
- `HARMONY_*_MIDI` is still absent from Arrangement in a meaningful way
|
||||
- the project still has large obvious silence islands with no explanation
|
||||
- the report claims success but the set still looks geometrically mirrored
|
||||
- snare handling is “fixed” by crude blacklist instead of contextual scoring
|
||||
- Codex final verdict is not `pass`
|
||||
|
||||
## Recommended Ralph Routing
|
||||
|
||||
Use the Ralph defaults already configured locally:
|
||||
|
||||
- implementer: `zai_glm51`
|
||||
- reviewers: `dashscope_qwen3coder_plus`, `dashscope_glm5`
|
||||
- Codex master: enabled
|
||||
|
||||
## Operator Note
|
||||
|
||||
This task is intended for the 24/7 Ralph queue.
|
||||
|
||||
Suggested submit command:
|
||||
|
||||
```powershell
|
||||
powershell -ExecutionPolicy Bypass -File .\ralph\scripts\Submit-RalphTask.ps1 `
|
||||
-SourceFile .\docs\SPRINT_v0.1.41_NEXT_RALPH_OPEN_PROJECT_EDITING.md
|
||||
```
|
||||
Reference in New Issue
Block a user