Files
ableton-mcp-ai/docs/SPRINT_v0.1.21_NEXT_GLM.md

9.0 KiB

Sprint v0.1.21 - GLM Runtime Truth, Anti-Loop Real, Zero Auto Vocals

Owner: GLM via OpenCode
Reviewer: Codex
Fecha: 2026-04-01
Baseline real vigente: a6a4cc87e493
Estado de cierre v0.1.20: no cerrado


1. Verdad operativa despues del review de Codex

El reporte [SPRINT_v0.1.20_VALIDATION_REPORT.md](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.20_VALIDATION_REPORT.md) fue mejor que varios reports previos en honestidad, pero sigue sin cerrar runtime.

Problemas concretos detectados por Codex:

  1. no aporta una sesion nueva persistida que cierre el sprint
  2. sigue apoyandose demasiado en “claims verified against code”
  3. el fix anti-loop principal se hizo sobre una helper path que no esta demostrada como activa en runtime
  4. el sistema seguia mostrando vocals en manifests viejos y el report no cerraba esa fuga end-to-end

Codex ya dejo aplicados fixes reales en [server.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py):

  • sanitizacion defensiva de capas vocales manual-only
  • inferencia de role desde nombres de layer
  • persistencia de positions en audio_layers
  • repetition_metrics robusto contra sections[*].end = None

Codex tambien endurecio tests en [test_piano_forward.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\tests\test_piano_forward.py):

  • purge de vocal layers
  • repeticion con sections sin end

Validado por Codex:

  • py_compile pasa
  • test_piano_forward.py pasa
  • test_selection_coherence.py pasa

No hubo generacion nueva en este turno.


2. Hallazgos importantes que GLM tiene que tomar como constraints

A. El anti-loop “implementado” no esta demostrado en el path activo

GLM toco _apply_clip_consolidation() en [server.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py), pero hoy ese helper no esta demostrado como parte del camino runtime que construye la cancion final.

Eso significa:

  • el cambio puede ser correcto como idea
  • pero no cuenta como fix real hasta que se pruebe impacto en una sesion nueva

No quiero otro sprint donde:

  • el helper mejora
  • el resultado audible sigue igual

B. repetition_metrics existia pero estaba roto para manifests reales

En manifests reales recientes:

  • sections[*].end viene como None
  • audio_layers viejos no siempre traen positions
  • audio_layers viejos no siempre traen role

Eso ya fue corregido por Codex para nuevas generaciones. GLM no debe reabrir ese bug.

C. La fuga vocal era de punta a punta, no de una sola capa

La politica manual-only no se cerraba solo en reference_listener.py. Habia que defender tambien:

  • materializacion
  • fallback
  • manifest
  • layer records

GLM debe asumir que cualquier fix vocal que no cierre esos cuatro puntos no sirve.

D. Hay evidencia mixta sobre hook MIDI

No es correcto decir simplemente “hook materialization failing consistently”.

Verdad real observada en manifests:

  • 4c697638bd3d: hook materialized true
  • ba306bd7575b: hook materialized true
  • a6a4cc87e493: hook materialized false

La conclusion correcta no es “siempre falla”. La conclusion correcta es:

  • el hook es inestable
  • no esta resuelto
  • requiere validacion sobre una sesion nueva

3. Objetivo real del sprint

Cerrar la brecha entre:

  • fixes de codigo
  • y resultado musical real

La prioridad absoluta es esta:

  1. cero vocals automaticas
  2. anti-loop real en el resultado final
  3. creatividad por seccion
  4. hibrido library + MIDI + piano verificable
  5. manifest que refleje verdad runtime

No quiero otro sprint centrado en helpers muertos o reportes “in progress”.


4. Reglas no negociables

  1. Trabajar solo en el arbol canonico:

    • C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts
  2. No tocar wrappers/config MCP salvo bug concreto y demostrado.

  3. Cero vocals automaticas:

    • no seleccion
    • no materializacion
    • no persistencia en audio_layers
    • no tracks AUDIO VOCAL *
    • no justificarlo como FX o “color”
  4. No reportar anti-loop si no afecta el path runtime real.

  5. No cerrar el sprint si no existe una sesion nueva persistida.

  6. No aceptar session_id inventados o viejos como sustituto de validacion fresca.

  7. No cerrar el sprint si cualquiera de estas falla:

    • coherence_score < 6.5
    • mandatory_midi_hook.materialized != true
    • piano_presence.piano_layer_count < 1
    • repetition_metrics.verdict == repetitive
    • generation_mode != library-first-hybrid
    • aparece cualquier vocal auto-generada

5. Trabajo obligatorio

P0. Atacar el path activo, no helpers secundarios

Antes de tocar nada:

  • identifica exactamente que funciones corren en la generacion real
  • no supongas que una helper afecta runtime solo porque existe

Pistas actuales del path activo:

  • song_generator.py construye secciones, variantes, phrase plan y track specs
  • reference_listener.py construye build_arrangement_plan()
  • server.py materializa audio/midi y persiste el manifest
  • el anti-loop real hoy probablemente pasa mas por:
    • song_generator.py
    • _build_audio_pattern_positions()
    • _materialize_reference_audio_layers()
    • consolidacion de duplicados

No alcanza con tocar _apply_clip_consolidation() si no demostras que esa ruta corre.

P1. Anti-loop real en musica, no solo en drums

Quiero foco en lo que el usuario oye como loop plano:

  • synth_loop
  • synth_peak
  • perc_loop
  • top_loop
  • material melodico y armonico por seccion

Tenes que demostrar que:

  • intro/build/drop/break no comparten la misma firma musical
  • el material melodico no se repite como copia casi exacta
  • los layers musicales no se reducen a un unico loop dominante toda la cancion

P2. Creatividad por seccion

Revisar a fondo en [song_generator.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\song_generator.py):

  • SectionVariationManager
  • PhrasePlan
  • pattern banks
  • elecciones de variante por seccion

No me sirve que exista infraestructura si el audio final suena igual.

Objetivo:

  • contraste real entre secciones
  • sin romper coherencia armonica

P3. Hibrido real

No acepto una generacion que sea:

  • solo loops
  • o solo pluck MIDI aislado
  • o piano solo en metadata

GLM tiene que cerrar:

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

P4. Vocal policy end-to-end

Verificar en una sesion nueva:

  • no tracks AUDIO VOCAL *
  • no roles vocales en audio_layers
  • no roles vocales en layer_selections
  • no roles vocales en selected/layers del plan final

Si aparece uno solo, el sprint no cierra.


6. Casos de test obligatorios

Minimo tenes que dejar o endurecer tests para:

  1. repetition_metrics con sections reales que tienen end=None
  2. layers vocales purgados de manifest
  3. ausencia de AUDIO VOCAL * en persistencia final
  4. preservacion de variacion por seccion en el path runtime que realmente corre
  5. hook MIDI materializado
  6. presencia real de piano o keys en el hibrido final

No borres tests de Codex.


7. Validacion final obligatoria

Al final del sprint tenes que hacer una generacion nueva real.

Parametros:

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

Tenes que demostrar con session_id nuevo y persistido:

  • coherence_score >= 6.5
  • generation_mode = library-first-hybrid
  • mandatory_midi_hook.materialized = true
  • piano_presence.piano_layer_count >= 1
  • repetition_metrics.verdict != repetitive
  • repetition_metrics.harmonic_loop_reuse_ratio < 0.75
  • repetition_metrics.music_source_reuse_ratio < 0.80
  • layer_selections.summary.total_layers > 0
  • cero vocals auto-generadas

Si no llegas:

  • no declares “partial complete”
  • no declares “blocked” sin evidencia nueva
  • explica exactamente donde esta el cuello de botella

8. Formato obligatorio del validation report

El report final de GLM debe tener estas secciones:

  1. Executive Summary
  2. Claims Verified Against Code
  3. Fresh Session Validation
  4. Manifest Truth
  5. Coherence Metrics
  6. Repetition Metrics
  7. Hybrid Truth (MIDI + Piano + Library)
  8. Instrumental-Only Compliance
  9. Open Issues
  10. Verdict

Y debe incluir:

  • session_id real
  • extracto real de generation_manifests.json
  • archivos tocados
  • tests corridos
  • thresholds con PASS/FAIL

No acepto:

  • “code complete”
  • “validation blocked”
  • “anti-loop implemented”

si no hay evidencia runtime fresca.


9. Criterio de cierre

Este sprint solo cierra si GLM demuestra simultaneamente:

  • menos loop plano
  • mas creatividad real
  • coherencia mejor
  • hook y piano reales
  • cero vocals automaticas
  • y manifest alineado con runtime

Si falla uno solo de esos puntos, el sprint sigue abierto.