ableton-mcp-ai/docs/SPRINT_v0.1.39_NEXT_GLM_OPEN_PROJECT_VARIATION.md

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 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.