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.23_NEXT_GLM.md

11 KiB
Raw Blame History

Sprint v0.1.23 - GLM Coherence-First, Anti-Same-Song, Zero Auto Vocals

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

1. Verdad operativa despues del review de Codex

El archivo [SPRINT_v0.1.22_NEXT.md](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\SPRINT_v0.1.22_NEXT.md) que dejo Minimax no es un handoff correcto de sprint. Es mas bien un changes report parcial con conclusiones inestables y con preguntas abiertas que no estaban cerradas en codigo ni en runtime.

Codex verifico contra:

  • generation_manifests.json
  • [server.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\server.py)
  • [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py)
  • [song_generator.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\song_generator.py)

Verdad real observada hoy:

  1. el last_generation_id vigente es ccb998a08796
  2. los manifests recientes siguen sin reflejar cierre real de coherencia
  3. generation_mode sigue viniendo None en sesiones recientes
  4. piano_presence.piano_layer_count sigue en 0 en sesiones recientes
  5. repetition_metrics sigue ausente en sesiones recientes
  6. el hook MIDI no falla siempre, pero sigue siendo inestable
  7. la sensacion auditiva del usuario es correcta: el sistema esta cayendo otra vez en la misma cancion

No generes otra sesion hasta que cierres las causas de codigo de esa repeticion.

2. Code Review de Codex: causas probables de "misma cancion siempre"

A. La variacion por seccion esta sesgada a roles secundarios

En [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py):

  • SECTION_VARIATION_ROLES existe
  • el bloque de section_samples en build_arrangement_plan() aplica variacion real solo a:
    • perc
    • perc_alt
    • top_loop
    • synth_peak
    • atmos

Pero los roles que mas identidad musical fijan siguen casi globales:

  • bass_loop
  • synth_loop

Eso hace que el track cambie adornos, pero no cambie el nucleo musical. Resultado audible: misma cancion, misma paleta, mismo centro melodico.

B. La macro-estructura sigue demasiado templada

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

  • _build_sections() sigue trabajando sobre blueprints muy repetidos
  • reaparecen constantemente patrones tipo:
    • INTRO
    • DROP A
    • BREAKDOWN
    • BUILD B
    • DROP B

Aunque exista variant_seed, el esqueleto alto nivel sigue demasiado similar entre generaciones. Resultado audible: el usuario percibe que la estructura siempre vuelve al mismo guion.

C. El anti-loop no puede declararse resuelto si toca helpers no demostradas como activas

Minimax dio demasiado peso a cambios en helpers y a claims tipo "active path fixed", pero Codex verifico que:

  • _apply_clip_consolidation() sigue sin demostrar uso real en el path runtime final
  • tocar una helper sin probar efecto en la sesion final no cuenta como cierre

GLM tiene que demostrar con trazabilidad que el fix que haga corre en la generacion real.

D. La politica vocal seguia ambigua en el plan

Aunque ya habia filtros y purgas posteriores, [reference_listener.py](C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\AbletonMCP_AI\AbletonMCP_AI\MCP_Server\reference_listener.py) seguia construyendo posiciones vocales dentro de build_arrangement_plan().

Codex ya cerro ese leak adicional:

  • se bloquea vocal_loop
  • se bloquea vocal_shot
  • se fuerza vocal_alt = None
  • se saca vocal_shot del role_match_map

Eso ya no debe reabrirse.

E. La creatividad se movio del material principal a los bordes

Hoy el sistema puede variar:

  • fills
  • percusiones secundarias
  • atmos
  • algun peak synth

Pero no esta variando suficiente:

  • la armonia principal
  • el loop musical dominante
  • el bajo dominante
  • la distribucion de motivos entre secciones

Eso no es creatividad estructural. Es decoracion.

3. Fixes ya aplicados por Codex en este turno

Codex dejo fixes concretos antes de entregarte este sprint:

reference_listener.py

  • bloqueo adicional de vocals dentro de build_arrangement_plan()
  • ya no se deja pasar selected["vocal_loop"]
  • ya no se deja pasar selected["vocal_shot"]
  • vocal_alt queda forzado a None
  • vocal_shot fue removido del mapa de variacion por seccion

test_piano_forward.py

  • test endurecido para verificar que:
    • plan["layers"] no contenga roles vocales
    • plan["section_samples"] no contenga claves vocales

GLM no debe revertir estos cambios.

4. Objetivo real del sprint

Recuperar dos cosas al mismo tiempo:

  1. coherencia real
  2. creatividad real

Y hacerlo sin reabrir:

  • vocals automaticas
  • manifests mentirosos
  • helpers no activas disfrazadas de fix

La meta no es "hacer mas compleja la generacion". La meta es que deje de sonar al mismo tema con ropa distinta.

5. Reglas no negociables

  1. Trabajar solo en el arbol canonico:

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

  2. No tocar wrappers ni config MCP salvo bug concreto reproducido.

  3. No reabrir vocals automaticas:

    • no seleccion
    • no section plan
    • no materializacion
    • no persistencia
    • no tracks AUDIO VOCAL *

  4. No declarar anti-loop resuelto si el cambio esta en una helper no probada en runtime.

  5. No cerrar el sprint con manifests viejos o inventados.

  6. No cerrar el sprint sin una sesion nueva persistida y verificable.

  7. No aceptar como "creatividad" cambiar solo perc/fills/FX.

  8. No degradar coherencia armonica por buscar variedad.

6. Trabajo obligatorio para GLM

P0. Atacar la identidad musical principal, no solo adornos

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

  • build_arrangement_plan()
  • section_samples
  • SECTION_VARIATION_ROLES
  • logica de bass_positions
  • logica de synth_positions

Objetivo:

  • synth_loop no puede quedar fijo globalmente durante toda la cancion
  • bass_loop no puede quedar fijo globalmente durante toda la cancion
  • tiene que existir variacion musical principal por seccion, no solo por FX

No significa randomizar sin control. Significa introducir contraste controlado y coherente.

P1. Recuperar creatividad estructural en song_generator.py

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

  • SECTION_BLUEPRINTS
  • SECTION_BLUEPRINT_VARIANTS
  • _build_sections()
  • SectionVariationManager
  • PhrasePlan

Objetivo:

  • bajar la repeticion de la macro-estructura
  • ampliar diversidad real de blueprints para reggaeton/perreo
  • evitar que todas las generaciones vuelvan al eje:
    • intro
    • drop a
    • breakdown
    • build b
    • drop b

Quiero variedad controlada de:

  • duraciones
  • orden de break/build
  • distribucion de densidad
  • rol del piano/keys entre intro, break y build

P2. Variacion armonica coherente, no caos

Tenes que reforzar la coherencia sin aplanar creatividad.

Objetivo musical:

  • una familia primaria clara
  • familias secundarias compatibles
  • mas presencia de piano/keys/rhodes
  • menos sensación de "mismo loop completo pegado en todas las secciones"

Pero:

  • no rompas la tonalidad
  • no rompas el hook
  • no metas sonidos que parezcan de otro track

P3. Persistencia y metricas de verdad

Hoy los manifests recientes siguen viniendo flojos:

  • generation_mode = None
  • piano_presence = 0
  • repetition_metrics = None

Eso no puede seguir.

GLM tiene que cerrar el wiring real para que la sesion nueva persistida refleje:

  • generation_mode
  • piano_presence
  • repetition_metrics
  • coherence_metrics

No como metadata de papel. Como verdad del resultado generado.

P4. Cero vocals automaticas end-to-end

Verificar otra vez todo el path:

  • seleccion
  • arrangement plan
  • materializacion
  • manifest

Si aparece una sola capa vocal auto-generada, el sprint no cierra.

7. Casos de test obligatorios

Minimo tenes que dejar o endurecer tests para:

  1. variacion seccional de synth_loop o material armonico principal en el path activo
  2. variacion seccional de bass_loop o bajo principal en el path activo
  3. ausencia total de roles vocales en section_samples
  4. ausencia total de roles vocales en layers
  5. persistencia real de repetition_metrics
  6. persistencia real de generation_mode
  7. persistencia real de piano_presence
  8. no regresion de coherencia basica

No borres tests de Codex. No reemplaces tests concretos por asserts vagos.

8. Validacion final obligatoria

Al final del sprint tenes que hacer una generacion nueva real con:

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

Y tenes que demostrar con session_id nuevo y persistido:

  1. coherence_score >= 6.5
  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. cero vocals automaticas
  7. evidencia audible de que no es la misma cancion que la anterior

Criterio auditivo obligatorio

En el report final no alcanza con metrics. Tenes que describir con precision:

  • que cambio entre intro/build/drop/break
  • que material principal varia
  • que sonidos dejaron de repetirse igual
  • por que ya no suena al mismo track de siempre

Si no podes explicarlo claramente, no esta cerrado.

9. Formato obligatorio del validation report

El archivo final debe llamarse:

  • SPRINT_v0.1.23_VALIDATION_REPORT.md

Y debe tener estas secciones, en este orden:

  1. Runtime Truth
  2. Code Changes
  3. Code Review Findings Addressed
  4. Fresh Session Evidence
  5. Manifest Metrics
  6. Anti-Same-Song Validation
  7. Manual Vocal Policy Validation
  8. Open Issues
  9. Verdict

Reglas del report

  1. No usar session_id viejos.
  2. No usar frases tipo should now.
  3. No escribir fixed si no hay evidencia en sesion nueva.
  4. Si algo no cerro, ponerlo como OPEN.
  5. Si la creatividad sigue floja, decirlo.

10. Definicion de done real

Este sprint solo cierra si:

  1. la cancion deja de sentirse como la misma estructura con los mismos sonidos
  2. la creatividad vuelve al material principal, no solo a adornos
  3. la coherencia sube en vez de bajar
  4. no hay ninguna vocal automatica
  5. el manifest final refleja la verdad real del runtime

Si falta cualquiera de esos cinco puntos, el sprint no esta cerrado.

Reference in New Issue View Git Blame Copy Permalink