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

7.8 KiB
Raw Permalink Blame History

SPRINT v0.1.27 - NEXT (GLM)

Continuity First, Piano Melodies, Smarter Drum Coherence

Owner: GLM via OpenCode
Reviewer: Codex
Fecha: 2026-04-02
Baseline report: 74bf4cbec05e
Baseline real vigente: 0345711a8749
Estado actual: estructura menos clonada, pero sigue WEAK y demasiado cortada

1. Runtime Truth

No cierres este sprint con el md de validacion solamente.

La verdad persistida actual es la sesion 0345711a8749 en C:\Users\ren\.abletonmcp_ai\generation_manifests.json.

Hechos reales hoy:

  • generation_mode = library-first-hybrid
  • mandatory_midi_hook.materialized = true
  • coherence_score = 4.6
  • coherence_verdict = WEAK
  • family_adherence_rate = 0.5
  • piano_presence.has_audio_piano = true
  • el audio piano sigue entrando como chords, no como melodia real dominante
  • el sistema ya no cae siempre en la misma estructura exacta
  • pero sigue sonando demasiado picado, con huecos y entradas tardias innecesarias

Importante:

  • el report docs/SPRINT_v0.1.26_VALIDATION_REPORT.md quedo desfasado
  • habla de 74bf4cbec05e, pero el last_generation_id real ya es 0345711a8749
  • no uses el report como source of truth si no coincide con el manifest real

2. Code Review

2.1 Que estaba mal en v0.1.26

  1. reference_listener.py La variacion de Drop B se logro quitando material:

    • perc mas espaciada
    • top loop entrando tarde
    • synth entrando tarde y con step alterado

    Eso daba "diferencia", pero por subtraction. Auditivamente suena mas cortado, no mas creativo.

  2. reference_listener.py El filtro MIN_PLACEMENTS_FOR_MUSICAL_LAYERS estaba aplicado por sample-path, no por presencia total del layer.

    Eso es un bug serio:

    • las variantes seccionales de synth/bass/top_loop podian tener 1-2 placements cada una
    • el filtro las borraba individualmente
    • el resultado final quedaba con huecos o con un solo fragmento sobreviviente

  3. reference_listener.py El piano habia mejorado, pero seguia casi siempre como AUDIO KEYS SUPPORT con rol chords.

    Eso sirve para soporte armonico. No sirve para responder al pedido actual del usuario: "quiero que el piano haga melodias"

  4. server.py music_source_reuse_ratio seguia midiendo casi al nivel de pack, no al nivel de sample real.

    Eso podia dar 1.0 aunque el sistema estuviera usando varios archivos distintos del mismo pack. Ese numero no era confiable para juzgar monotonia real.

  5. reference_listener.py El section_character_bonus estaba siendo llamado con argumentos invertidos en el path de matching.

    Eso contamina la selectividad de caracter, incluyendo drums. Era un bug real de runtime, no de logs.

2.2 Que ya corrigio Codex en este turno

  • se elimino la diferenciacion por vaciado artificial en Drop B
  • se preservan variantes seccionales sin borrarlas por tener pocos placements por sample-path
  • se agrego AUDIO PIANO MELODY cuando hay material piano/keys melodico disponible
  • music_source_reuse_ratio ahora usa keys de source a nivel sample, no solo pack
  • se corrigio el call-order roto de section_character_bonus
  • se agrego selectividad contextual para snare/clap en secciones mas suaves

Eso ya esta en codigo. No lo reviertas.

3. Nuevo Criterio Del Usuario

Hay una observacion especifica que a partir de ahora es obligatoria:

SS_RNBL_Me_Gustas_One_Shot_Snare.wav

No hard-banear este sample. No hacer un if bruto para excluirlo.

Lo correcto es:

  • entender por que el scorer lo deja entrar
  • volver mas selectiva la coherencia de drums
  • permitirlo solo cuando el contexto del tema realmente pida ese snare agresivo

Interpretacion senior:

  • si una seccion tiene energia media, brillo moderado y no esta pidiendo un clap/snare tan duro, ese sample debe perder ranking
  • si la seccion es realmente agresiva y el contexto percutivo lo soporta, puede seguir siendo elegible

No conviertas este punto en una blacklist. Convertilo en selectividad contextual real.

4. Objetivo Real de v0.1.27

Recuperar continuidad musical sin volver a la cancion clonada.

La salida buscada es:

  • estructura clara
  • identidad coherente
  • menos huecos absurdos
  • menos entradas tardias solo para "simular variacion"
  • piano melodico audible
  • drums mas selectivos y contextuales

La salida NO buscada es:

  • volver a la misma cancion siempre
  • volver a un tema vaciado por silencios
  • meter piano solo como relleno de acordes
  • hardcodear excludes por sample

5. Trabajo Obligatorio

P0. Validar el nuevo path de continuidad real

Hay que probar con generacion nueva y confirmar que los fixes de continuidad realmente se vean en el manifest y en el audio:

  • Drop B no debe diferenciarse solo por silencio o ausencia
  • synth_loop, top_loop, bass_loop no deben desaparecer por filtros internos
  • si hay variacion entre secciones, que sea por material, densidad util o articulacion; no por vaciar media barra

Que revisar:

  • audio_layers[*].positions
  • secciones build/drop/break
  • si el mismo rol aparece con variantes seccionales, que no se pierdan por filtrado

P0. Piano melodico real

No alcanza con AUDIO KEYS SUPPORT.

Objetivo:

  • validar que AUDIO PIANO MELODY aparezca cuando haya material apto
  • que el piano melodico no quede solo en el break o como detalle marginal
  • que aporte fraseo/motivo, no solo cama armonica

Reglas:

  • no reemplazar toda la identidad pluck del tema
  • el piano melodico debe convivir con la familia primaria, no romperla
  • usar piano/keys/rhodes melodico solo cuando el sample realmente sea melodico

P0. Repeticion real medida por sample, no por pack

Con el fix nuevo, music_source_reuse_ratio debe reevaluarse con una sesion nueva.

Objetivo:

  • medir monotonia real
  • no castigar injustamente el uso coherente de un mismo pack

Que revisar:

  • repetition_metrics.source_distribution
  • music_source_reuse_ratio
  • cuantas fuentes musicales distintas hay realmente

P1. Selectividad de snare/clap por contexto

No hacer blacklist de SS_RNBL_Me_Gustas_One_Shot_Snare.wav.

Trabajo esperado:

  • validar que el call-order corregido de section_character_bonus ya cambie el ranking
  • revisar si hace falta endurecer la selectividad tambien en sample_selector.py
  • demostrar con evidencia de ranking o manifest que snares muy agresivos no ganan por default en secciones que no lo piden

Si tocas scoring:

  • hacelo generico y explicable
  • basado en brillo/transient/contexto
  • no basado en un nombre de archivo puntual

6. Exit Criteria

No cierres el sprint si no se cumple todo esto con una sesion nueva persistida:

  • generation_mode = library-first-hybrid
  • mandatory_midi_hook.materialized = true
  • coherence_score >= 6.0
  • family_adherence_rate >= 0.65
  • pack_coherence.overall >= 0.6
  • piano_presence.has_audio_piano = true
  • AUDIO PIANO MELODY presente o evidencia clara de piano melodico equivalente
  • repetition_metrics.verdict != repetitive
  • music_source_reuse_ratio < 0.8 con la nueva metrica por sample real
  • vocal_layers_auto = 0

Criterio auditivo obligatorio:

  • menos cortes y huecos que 0345711a8749
  • el piano debe escucharse como recurso melodico, no solo armonico
  • Drop A y Drop B deben diferenciarse sin vaciar artificialmente el groove

7. Validation Report Obligatorio

GLM tiene que dejar:

docs/SPRINT_v0.1.27_VALIDATION_REPORT.md

Y ese md debe incluir:

  1. session_id real nuevo
  2. comparativa contra 0345711a8749
  3. manifest evidence real, no logs sueltos
  4. audio_layers relevantes con positions de:
    • AUDIO SYNTH LOOP
    • AUDIO BASS LOOP
    • AUDIO TOP LOOP
    • AUDIO KEYS SUPPORT
    • AUDIO PIANO MELODY
  5. repetition_metrics.source_distribution
  6. evidencia de que el snare agresivo no esta entrando por default si no corresponde

Si el md no compara contra el manifest real mas nuevo, el sprint no cuenta.

Reference in New Issue View Git Blame Copy Permalink