renato97/ableton-mcp-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
6d080d43b3c869e644c709f0b13bead55fe66559
ableton-mcp-ai/docs/SPRINT_v0.1.24_NEXT_GLM.md

9.3 KiB
Raw Blame History

Sprint v0.1.24 - GLM Runtime Truth, Hybrid Recovery, Anti-Same-Song Real

Owner: GLM via OpenCode
Reviewer: Codex
Fecha: 2026-04-02
Baseline real vigente: 6df5c445aa1e
Estado de cierre v0.1.23: no cerrado

1. Verdad operativa despues del review de Codex

El reporte [SPRINT_v0.1.23_VALIDATION_REPORT.md](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.23_VALIDATION_REPORT.md) no cierra el sprint y quedo desactualizado en dos puntos importantes:

  1. el claim de MCP timeout no es valido como blocker general
  2. hoy si existe una sesion nueva persistida: 6df5c445aa1e

Codex verifico runtime real:

  • get_session_info() responde bien contra Live
  • no hay bloqueo general del MCP

Codex verifico la sesion nueva 6df5c445aa1e en generation_manifests.json:

  • genre = reggaeton
  • style = perreo duro vieja escuela tipo safaera
  • reference_path = None
  • generation_mode = midi-first
  • mandatory_midi_hook.materialized = false
  • piano_presence.piano_layer_count = 0
  • repetition_metrics = None
  • coherence_metrics = None
  • tracks_blueprint = 0

Conclusion:

  • GLM no valido el flujo pedido con referencia
  • la sesion nueva no demuestra el path library-first-hybrid
  • el trabajo en reference_listener.py por si solo no alcanza si el runtime cae otra vez a midi-first

2. Code Review de Codex sobre lo que hizo GLM

A. El reporte confunde ausencia de validacion con bloqueo real

GLM dejo MCP timeout como explicacion principal, pero Codex comprobo que el MCP si responde.

Regla nueva:

  • no volver a usar MCP timeout como excusa general sin comando reproducible, timestamp y evidencia concreta

B. GLM mejoro el path activo, pero dejo dos bugs reales en la variacion armonica

GLM agrego variacion para synth_loop y bass_loop en [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py). La idea iba en la direccion correcta, pero habia dos bugs:

  1. la variacion seccional seguia usando el step del sample global, no el del sample alternativo real
  2. si solo quedaba un sample alternativo en positions_by_sample, add_layer() seguia atribuyendo el layer al asset global en vez del sample realmente usado

Eso hace que:

  • la variacion pueda quedar mal cuantizada
  • el manifest pueda mentir sobre que sample sono realmente

Codex ya dejo corregido esto.

C. Los tests nuevos de GLM eran demasiado debiles

GLM agrego tests que verificaban principalmente:

  • que existan constantes
  • que ciertas secciones esten en un set

Eso no prueba comportamiento runtime.

Codex ya endurecio la suite con un test que valida el path real:

  • build_arrangement_plan() debe usar el sample armonico alternativo
  • y debe respetar su loop_step real

D. La sesion nueva demuestra otro problema mas importante

La sesion 6df5c445aa1e no uso referencia:

  • reference_path = None
  • reference_name = None

Entonces:

  • no valida el caso pedido por el sprint
  • no prueba anti-same-song sobre el flujo referenciado
  • no prueba coherencia de libreria
  • no prueba el hibrido con hook + piano + libreria

E. La regresion estructural sigue abierta

Aunque GLM agrego blueprints nuevos en [song_generator.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\song_generator.py), no hay evidencia de que el usuario este escuchando eso en el path real.

Hasta que no exista una sesion nueva persistida que:

  • use referencia
  • quede en library-first-hybrid
  • y materialice diferencias seccionales reales

no se puede dar por cerrada la recuperacion de creatividad.

3. Fixes ya aplicados por Codex en este turno

reference_listener.py

Codex corrigio dos bugs de la variacion armonica:

  1. el step ahora se resuelve desde el sample realmente usado por seccion
  2. add_layer() ya no adjudica automaticamente el layer al asset global cuando el sample real era otro

Esto afecta el path activo de build_arrangement_plan().

test_piano_forward.py

Codex agrego un test real de comportamiento:

  • valida que build_arrangement_plan() materialice variacion armonica con loop_step del sample alternativo

GLM no debe revertir estos cambios.

4. Objetivo real del sprint

Cerrar la brecha entre:

  • cambios en reference_listener.py
  • y el resultado real que escucha el usuario

La prioridad absoluta ahora es:

  1. volver al flujo library-first-hybrid
  2. usar referencia real
  3. recuperar creatividad sin perder coherencia
  4. persistir metricas reales en manifest

No quiero otro sprint con mejoras locales correctas pero validadas sobre una sesion que no usa referencia.

5. Reglas no negociables

  1. Trabajar solo en el arbol canonico:

    • C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts

  2. No reabrir vocals automaticas.

  3. No usar sesiones sin referencia para cerrar un sprint de coherencia referenciada.

  4. No usar midi-first como cierre valido para este objetivo.

  5. No cerrar el sprint si la sesion nueva no cumple:

    • reference_path != None
    • generation_mode = library-first-hybrid
    • mandatory_midi_hook.materialized = true
    • piano_presence.piano_layer_count >= 1

  6. No declarar creatividad recuperada si la diferencia sigue estando solo en adornos.

  7. No aceptar tests que solo validen constantes o listas.

6. Trabajo obligatorio para GLM

P0. Recuperar el path correcto de generacion

Tenes que identificar por que la sesion nueva 6df5c445aa1e cayo en:

  • reference_path = None
  • generation_mode = midi-first
  • tracks_blueprint = 0

Eso es prioridad maxima.

Hay que cerrar el wiring desde:

  • request de generacion
  • lectura de referencia
  • build_arrangement_plan()
  • materializacion
  • persistencia de manifest

Hasta que eso no cierre, el resto de los claims musicales sigue en el aire.

P1. Anti-same-song en el path que realmente escucha el usuario

Una vez recuperado el flujo referenciado:

  • demostrar que synth_loop y/o bass_loop varian por seccion
  • demostrar que la estructura no cae siempre en el mismo blueprint percibido
  • demostrar que la creatividad vuelve al material principal

No alcanza con:

  • cambiar fills
  • cambiar perc loops
  • cambiar FX

P2. Persistencia real de metricas

Tenes que dejar funcionando de verdad en la sesion nueva:

  • coherence_metrics
  • repetition_metrics
  • generation_mode
  • piano_presence

No como None. No como placeholder. No como objeto vacio.

P3. Hibrido real

Quiero evidencia real de:

  • referencia cargada
  • libreria usada
  • hook MIDI creado
  • piano/keys presentes
  • audio y MIDI conviviendo

Si sigue saliendo midi-first, el sprint no cierra.

P4. Validacion de verdad del manifest

Comparar la sesion nueva contra el set real y asegurar:

  • que el manifest no miente sobre los samples usados
  • que los layers armonicos reflejan el sample realmente materializado
  • que la variacion seccional no queda perdida al persistir

7. Casos de test obligatorios

Minimo tenes que dejar o endurecer tests para:

  1. flujo con referencia que no termine en reference_path = None
  2. generation_mode = library-first-hybrid cuando hay referencia y plan hibrido
  3. persistencia real de coherence_metrics
  4. persistencia real de repetition_metrics
  5. persistencia real de piano_presence
  6. materializacion real del hook MIDI
  7. variacion armonica seccional usando el sample real, no el asset global

No borres tests de Codex.

8. Validacion final obligatoria

Al final del sprint tenes que generar una sesion nueva real con:

  • genre = reggaeton
  • style = perreo duro vieja escuela tipo safaera
  • referencia:
    • libreria\reggaeton\ejemplo.mp3

Y demostrar con session_id nuevo y persistido:

  1. reference_path presente
  2. generation_mode = library-first-hybrid
  3. mandatory_midi_hook.materialized = true
  4. piano_presence.piano_layer_count >= 1
  5. repetition_metrics.verdict != repetitive
  6. coherence_score >= 6.5
  7. cero vocals automaticas

Criterio auditivo obligatorio

En el report final tenes que explicar:

  1. que cambio en intro/build/drop/break
  2. que material principal dejo de repetirse igual
  3. como se mantuvo coherencia sin volver a la misma cancion

Si no podes explicarlo con precision, no esta cerrado.

9. Formato obligatorio del validation report

El archivo final debe llamarse:

  • SPRINT_v0.1.24_VALIDATION_REPORT.md

Y debe tener estas secciones, en este orden:

  1. Runtime Truth
  2. Code Changes
  3. Bugs Fixed From Codex Review
  4. Fresh Session Evidence
  5. Manifest Metrics
  6. Hybrid Validation
  7. Anti-Same-Song Validation
  8. Manual Vocal Policy Validation
  9. Open Issues
  10. Verdict

Reglas del report

  1. No usar MCP timeout sin evidencia reproducible.
  2. No usar sesiones sin referencia para cerrar este sprint.
  3. No usar lenguaje hipotetico tipo should now.
  4. Si algo sigue abierto, poner OPEN.
  5. Si la sesion cae en midi-first, decirlo explicitamente.

10. Definicion de done real

Este sprint solo cierra si:

  1. el flujo vuelve a usar referencia real
  2. el resultado vuelve a ser library-first-hybrid
  3. la creatividad se recupera en el material principal
  4. la coherencia sube en vez de bajar
  5. el manifest refleja la verdad runtime

Si falla cualquiera de esos cinco puntos, no esta cerrado.

Reference in New Issue View Git Blame Copy Permalink