Sync: Complete project state with all MEGA SPRINT V1-V3 features and Codex stubs
This commit is contained in:
renato97
451
docs/SPRINT_v0.1.39_NEXT_GLM_OPEN_PROJECT_VARIATION.md
Normal file
451
docs/SPRINT_v0.1.39_NEXT_GLM_OPEN_PROJECT_VARIATION.md
Normal file
@@ -0,0 +1,451 @@
|
||||
# SPRINT v0.1.39 - NEXT GLM
|
||||
## Open-Project Editing, Anti-Symmetry, Continuity, Coherence
|
||||
|
||||
**Owner:** GLM via OpenCode
|
||||
**Reviewer:** Codex
|
||||
**Fecha:** 2026-04-03
|
||||
**Mode:** Edit existing project, not generate a new song
|
||||
**Project target:** `C:\Users\ren\Desktop\song Project\song.als`
|
||||
|
||||
---
|
||||
|
||||
## 0. Executive Summary
|
||||
|
||||
El MCP mejoró de verdad para inspección y edición básica de proyectos abiertos, pero el problema musical actual ya no es “falta de wrappers”.
|
||||
|
||||
El problema real del proyecto abierto es este:
|
||||
|
||||
1. La canción sigue siendo demasiado simétrica.
|
||||
2. Los roles principales repiten exactamente los mismos clips/sample blocks en patrones demasiado previsibles.
|
||||
3. Hay demasiados huecos y silencios entre bloques.
|
||||
4. La armonía MIDI sigue sin sostener el tema en Arrangement.
|
||||
5. La coherencia existe a nivel de pack/familia, pero la libertad sonora es demasiado baja y termina sonando mecánica.
|
||||
|
||||
Este sprint no es para “agregar más tools porque sí”.
|
||||
Es para conectar las métricas actuales con herramientas de reparación reales sobre el `.als` abierto.
|
||||
|
||||
---
|
||||
|
||||
## 1. Runtime Truth You Must Start From
|
||||
|
||||
No tomar [SPRINT_v0.1.38_VALIDATION_REPORT.md](C:/ProgramData/Ableton/Live%2012%20Suite/Resources/MIDI%20Remote%20Scripts/docs/SPRINT_v0.1.38_VALIDATION_REPORT.md) como verdad suficiente.
|
||||
|
||||
La verdad runtime al momento de este handoff es:
|
||||
|
||||
- Proyecto abierto a `95 BPM`
|
||||
- `16` tracks
|
||||
- `4` return tracks
|
||||
- `6` scenes
|
||||
- La pista armónica está hoy como `HARMONY_AMIN_PLUCK`
|
||||
- Esa pista tiene `1` session clip y `0` arrangement clips
|
||||
|
||||
El problema no es abstracto. Está visible también en el Arrangement:
|
||||
|
||||
- `AUDIO KICK` repite el mismo one-shot en bloques a `32, 64, 96, 128, 160, 192, 224, 256`
|
||||
- `AUDIO CLAP` hace prácticamente lo mismo
|
||||
- `AUDIO HAT` hace prácticamente lo mismo
|
||||
- `AUDIO PERC MAIN` repite el mismo loop de `16` beats a lo largo del tema
|
||||
- `AUDIO PERC ALT` repite el mismo loop en menos bloques
|
||||
- `AUDIO TOP LOOP` repite el mismo top loop en secciones espejadas
|
||||
- `AUDIO SYNTH LOOP` usa el mismo clip largo en pocos bloques
|
||||
- `AUDIO SYNTH PEAK` entra en islas pequeñas, dejando demasiado vacío entre apariciones
|
||||
|
||||
Eso explica exactamente el feedback del usuario:
|
||||
|
||||
- “simétrico”
|
||||
- “todo lo mismo”
|
||||
- “muchos silencios”
|
||||
- “falta libertad”
|
||||
|
||||
---
|
||||
|
||||
## 2. Code Review Summary
|
||||
|
||||
### 2.1 What GLM got right
|
||||
|
||||
- Las tools de inspección de proyecto abierto ya son útiles:
|
||||
- `get_session_info`
|
||||
- `get_tracks`
|
||||
- `get_clips`
|
||||
- `get_devices`
|
||||
- `get_track_info`
|
||||
- Las tools básicas de edición Session ya funcionan razonablemente:
|
||||
- `create_clip`
|
||||
- `add_notes_to_clip`
|
||||
- `set_clip_name`
|
||||
- `set_clip_loop`
|
||||
- `delete_clip`
|
||||
- `fire_clip`
|
||||
- `stop_clip`
|
||||
- La auditoría de coherencia del proyecto abierto ya detecta huecos, sobreuso y pistas vacías.
|
||||
|
||||
### 2.2 What was still overclaimed or incomplete
|
||||
|
||||
- `create_arrangement_clip` y `duplicate_clip_to_arrangement` seguían siendo frágiles porque dependen del fallback `Session -> Arrangement`.
|
||||
- El reporte v0.1.38 validó edición de Session, no cierre fuerte de edición Arrangement.
|
||||
- `HARMONY_PIANO_MIDI` o su equivalente armónico seguía sin backbone real en Arrangement.
|
||||
|
||||
### 2.3 Bugs fixed by Codex in this review
|
||||
|
||||
No reabrir estos temas salvo que fallen con evidencia nueva:
|
||||
|
||||
1. `create_arrangement_clip` / `duplicate_clip_to_arrangement`
|
||||
- Se ampliaron timeouts del lado server y runtime para que el fallback no muera por grabación en tiempo real.
|
||||
|
||||
2. `get_device_parameters`
|
||||
- Se corrigió el acceso a `value_items` en parámetros no cuantizados.
|
||||
|
||||
3. `validate_key_conflicts`
|
||||
- Se corrigió el uso roto de helper legacy y ahora vuelve a leer el estado real vía conexión live.
|
||||
|
||||
4. `validate_set_detailed` y `diagnose_bus_routing`
|
||||
- Dejaron de depender de wrappers legacy inconsistentes.
|
||||
|
||||
5. `humanize_set`
|
||||
- Ya no se queda en `0` clips por leer mal la forma de `get_all_tracks`; ahora re-inspecciona session clips.
|
||||
|
||||
6. `COMMAND_TIMEOUTS`
|
||||
- Ya cubren edición de Arrangement MIDI, no solo audio pattern generation.
|
||||
|
||||
---
|
||||
|
||||
## 3. Product Direction For This Sprint
|
||||
|
||||
### 3.1 Primary goal
|
||||
|
||||
Convertir el MCP de “inspección + edición mínima” a “edición guiada por coherencia del proyecto abierto”.
|
||||
|
||||
### 3.2 Musical goal
|
||||
|
||||
Reducir simetría y silencios sin romper coherencia.
|
||||
|
||||
Eso significa:
|
||||
|
||||
- más libertad de elección de sonidos
|
||||
- menos repetición exacta del mismo clip
|
||||
- más continuidad entre secciones
|
||||
- más columna armónica MIDI en Arrangement
|
||||
- pero sin convertir el tema en un collage caótico
|
||||
|
||||
### 3.3 Important clarification about “piano”
|
||||
|
||||
Cuando el usuario habla de “piano roll”, interpretarlo como:
|
||||
|
||||
- **columna armónica MIDI**
|
||||
- **backbone de notas en Arrangement**
|
||||
|
||||
No interpretarlo como:
|
||||
|
||||
- obligar timbre de piano acústico
|
||||
- volver el track piano-forward
|
||||
|
||||
La pista `HARMONY_PIANO_MIDI` o `HARMONY_*` debe funcionar como backbone MIDI armónico mezclado con la librería del usuario.
|
||||
No hace falta perseguir un timbre de piano si musicalmente no corresponde.
|
||||
|
||||
---
|
||||
|
||||
## 4. Multi-Agent Requirement
|
||||
|
||||
Este sprint debe ejecutarse con dos focos de revisión paralelos:
|
||||
|
||||
1. `Agent Runtime`
|
||||
- tools MCP
|
||||
- edición de Arrangement
|
||||
- persistencia/re-inspection
|
||||
- timeouts
|
||||
- track/device/clip truth
|
||||
|
||||
2. `Agent Musical`
|
||||
- repetición
|
||||
- simetría
|
||||
- huecos
|
||||
- backbone armónico
|
||||
- libertad sonora con coherencia
|
||||
|
||||
No cerrar el sprint sin integrar findings de ambos.
|
||||
|
||||
---
|
||||
|
||||
## 5. Scope
|
||||
|
||||
### P0.1 Arrangement-first project editing truth
|
||||
|
||||
Implementar o cerrar una API de edición/inspección realmente útil sobre proyecto abierto.
|
||||
|
||||
Entregables mínimos:
|
||||
|
||||
- `get_project_edit_state(...)`
|
||||
- Debe devolver una vista consolidada del proyecto abierto:
|
||||
- tracks
|
||||
- clips
|
||||
- devices
|
||||
- longest gaps
|
||||
- repeated clip overuse
|
||||
- harmonic backbone status
|
||||
|
||||
- `get_arrangement_clip_info(...)`
|
||||
- Debe permitir inspeccionar clips de Arrangement por `track_index + start_time`
|
||||
- No puede depender solo de `clip_slots`
|
||||
|
||||
- `materialize_session_clip_to_arrangement(...)`
|
||||
- Tool explícita para pasar un clip Session a Arrangement sin ambigüedad de propósito
|
||||
- Debe re-inspeccionar después
|
||||
|
||||
### P0.2 Harmonic backbone repair
|
||||
|
||||
Crear una tool de reparación de columna armónica para proyecto abierto:
|
||||
|
||||
- `repair_harmonic_gaps(...)`
|
||||
|
||||
Debe:
|
||||
|
||||
- detectar huecos armónicos largos
|
||||
- usar la pista armónica MIDI existente
|
||||
- materializar clips/notas en Arrangement
|
||||
- rellenar huecos sin invadir todo el tema
|
||||
- respetar la identidad del proyecto abierto
|
||||
|
||||
No vale “crear un clip de 4 bars en Session y listo”.
|
||||
|
||||
### P0.3 Anti-symmetry / anti-loop repair
|
||||
|
||||
Crear una tool real de reducción de simetría:
|
||||
|
||||
- `reduce_repeated_clip_overuse(...)`
|
||||
o
|
||||
- `vary_repeated_audio_sections(...)`
|
||||
|
||||
Debe actuar sobre el proyecto abierto ya cargado.
|
||||
|
||||
Debe:
|
||||
|
||||
- detectar clips/sample blocks excesivamente repetidos
|
||||
- variar por secciones
|
||||
- no romper coherencia de pack/familia
|
||||
- no introducir samples arbitrarios por puro cambio
|
||||
|
||||
Regla musical:
|
||||
|
||||
- no repetir exactamente el mismo clip de audio en la misma función estructural durante todo el tema
|
||||
- permitir anchors coherentes
|
||||
- prohibir mirror placements triviales tipo `32/64/96/128/160/192/...` si no hay transformación real
|
||||
|
||||
### P0.4 Continuity repair
|
||||
|
||||
Crear una tool:
|
||||
|
||||
- `extend_track_continuity(...)`
|
||||
|
||||
Debe:
|
||||
|
||||
- reducir silencios innecesarios
|
||||
- extender continuidad de drum/musical support
|
||||
- usar el material ya presente o variantes coherentes
|
||||
- no llenar huecos con ruido o FX aleatorios
|
||||
|
||||
### P1.1 Device inspection/editing completeness
|
||||
|
||||
Mejorar herramientas públicas de edición:
|
||||
|
||||
- `get_track_info(track_type=...)` debe seguir siendo consistente
|
||||
- `get_device_parameters(...)` debe funcionar sobre Wavetable y otros devices comunes
|
||||
- `set_device_parameter(parameter_name=...)` debe quedar validado con nombres reales del proyecto abierto
|
||||
|
||||
### P1.2 Project coherence audit -> repair linkage
|
||||
|
||||
`audit_project_coherence()` y/o `audit_current_project()` ya no deben ser solo diagnóstico.
|
||||
|
||||
Agregar salida accionable:
|
||||
|
||||
- suggested repairs
|
||||
- target tracks
|
||||
- target gaps
|
||||
- repeated source hotspots
|
||||
- harmonic support gaps
|
||||
|
||||
---
|
||||
|
||||
## 6. Musical Rules
|
||||
|
||||
### 6.1 Freedom without chaos
|
||||
|
||||
Queremos más libertad sonora, pero con coherencia.
|
||||
|
||||
Eso significa:
|
||||
|
||||
- permitir más de un sample/loop por rol a lo largo de la canción
|
||||
- mantener compatibilidad por pack/familia/bus
|
||||
- variar por secciones
|
||||
- no clonar exactamente el mismo bloque en cada sección
|
||||
|
||||
No significa:
|
||||
|
||||
- meter sonidos nuevos por meter
|
||||
- romper el carácter del track
|
||||
- cambiar de pack cada 8 bars
|
||||
|
||||
### 6.2 Anti-symmetry rules
|
||||
|
||||
El proyecto actual cae demasiado en:
|
||||
|
||||
- mismos inicios de clip
|
||||
- mismas duraciones
|
||||
- misma ausencia/presencia entre bloques equivalentes
|
||||
|
||||
Tu trabajo es romper esa simetría de manera musical.
|
||||
|
||||
Ejemplos válidos:
|
||||
|
||||
- variar `AUDIO TOP LOOP` entre secciones A y B
|
||||
- hacer que `AUDIO SYNTH LOOP` sostenga más y no aparezca como isla aislada
|
||||
- introducir continuidad armónica MIDI donde hoy hay hueco
|
||||
- crear variación por transformación, no por borrado
|
||||
|
||||
Ejemplos inválidos:
|
||||
|
||||
- mutear media canción para “crear contraste”
|
||||
- duplicar exactamente el mismo loop en nuevas posiciones
|
||||
- reemplazar todo por samples random
|
||||
|
||||
### 6.3 Silence policy
|
||||
|
||||
Los silencios deben ser intencionales, no consecuencia de un planner pobre.
|
||||
|
||||
No aceptar:
|
||||
|
||||
- huecos largos sin función estructural clara
|
||||
- tramos donde se cae drums + armonía a la vez sin justificación
|
||||
|
||||
Sí aceptar:
|
||||
|
||||
- breaks intencionales
|
||||
- drops con respiración medida
|
||||
- intros/outros relativamente más aireados
|
||||
|
||||
### 6.4 Harmonic MIDI policy
|
||||
|
||||
`HARMONY_PIANO_MIDI` o su equivalente debe:
|
||||
|
||||
- existir como backbone MIDI audible
|
||||
- estar en Arrangement
|
||||
- cubrir una parte significativa del tema
|
||||
- ayudar a cerrar huecos
|
||||
- convivir con la librería del usuario
|
||||
|
||||
No perseguir “piano” como timbre obligatorio.
|
||||
Perseguir backbone MIDI armónico.
|
||||
|
||||
---
|
||||
|
||||
## 7. Acceptance Criteria
|
||||
|
||||
No marcar `COMPLETED` si falta cualquiera de estos puntos.
|
||||
|
||||
### Runtime / MCP
|
||||
|
||||
1. `get_project_edit_state(...)` existe y funciona sobre `song.als`
|
||||
2. `get_arrangement_clip_info(...)` o equivalente existe y prueba clips reales de Arrangement
|
||||
3. `materialize_session_clip_to_arrangement(...)` o equivalente queda validada con re-inspection
|
||||
4. `get_device_parameters(...)` funciona sobre un device real del proyecto abierto
|
||||
5. `set_device_parameter(parameter_name=...)` se valida con re-inspection
|
||||
|
||||
### Musical / coherence
|
||||
|
||||
1. La pista armónica MIDI deja de estar vacía en Arrangement
|
||||
2. `longest_harmonic_gap` baja de forma real
|
||||
3. `longest_drum_gap` baja de forma real
|
||||
4. Baja `repeated_clip_overuse`
|
||||
5. Se rompe la simetría excesiva de placements
|
||||
6. Disminuyen los silencios inútiles
|
||||
|
||||
### Truth
|
||||
|
||||
1. Validación solo sobre proyecto abierto real
|
||||
2. Re-inspection después de cada edición relevante
|
||||
3. No basarse solo en manifest ni en reporte textual
|
||||
|
||||
---
|
||||
|
||||
## 8. Required Validation Steps
|
||||
|
||||
### Step 1
|
||||
|
||||
Reiniciar OpenCode y Ableton antes de validar, porque hubo cambios en:
|
||||
|
||||
- `server.py`
|
||||
- `abletonmcp_init.py`
|
||||
- `abletonmcp_runtime.py`
|
||||
|
||||
### Step 2
|
||||
|
||||
Obtener baseline real:
|
||||
|
||||
- `get_session_info()`
|
||||
- `get_tracks()`
|
||||
- `get_track_info(track_index=<harmonic_track>)`
|
||||
- `audit_current_project()`
|
||||
- `audit_project_coherence()`
|
||||
|
||||
### Step 3
|
||||
|
||||
Aplicar edición real al proyecto abierto.
|
||||
|
||||
No generar una canción nueva.
|
||||
|
||||
### Step 4
|
||||
|
||||
Re-inspeccionar:
|
||||
|
||||
- clips
|
||||
- arrangement clips
|
||||
- devices
|
||||
- gaps
|
||||
- repeated clips
|
||||
|
||||
### Step 5
|
||||
|
||||
Comparar before/after con números reales.
|
||||
|
||||
---
|
||||
|
||||
## 9. Required Report
|
||||
|
||||
Guardar en:
|
||||
|
||||
- `docs/SPRINT_v0.1.39_VALIDATION_REPORT.md`
|
||||
|
||||
Estructura obligatoria:
|
||||
|
||||
1. Runtime truth before
|
||||
2. Tools added/changed
|
||||
3. Live edit actions performed
|
||||
4. Re-inspection after edits
|
||||
5. Before/after metrics
|
||||
6. Remaining blockers
|
||||
7. Reviewer conclusion
|
||||
|
||||
No usar `COMPLETED` si la pista armónica sigue sin Arrangement o si la canción sigue espejada y vacía.
|
||||
|
||||
---
|
||||
|
||||
## 10. Explicit Do-Nots
|
||||
|
||||
- No generar un tema nuevo
|
||||
- No declarar cierre usando solo Session clips
|
||||
- No usar “más libertad” como excusa para romper coherencia
|
||||
- No rellenar huecos con FX basura
|
||||
- No convertir “piano roll” en “piano timbre obligatorio”
|
||||
- No cerrar el sprint si el proyecto sigue viéndose como bloques simétricos con silencios entre medio
|
||||
|
||||
---
|
||||
|
||||
## 11. Reviewer Note
|
||||
|
||||
El sistema va muy bien en una cosa importante:
|
||||
|
||||
- ya puede inspeccionar el proyecto real
|
||||
- ya empieza a editarlo
|
||||
- ya puede medir dónde está fallando
|
||||
|
||||
El siguiente salto de calidad no viene de más heurísticas de generación.
|
||||
Viene de **editar bien el proyecto abierto** y usar la coherencia para decidir **qué reparar, qué extender, qué variar y qué dejar quieto**.
|
||||
Reference in New Issue
Block a user