336 lines
8.8 KiB
Markdown
336 lines
8.8 KiB
Markdown
# SPRINT v0.1.26 — NEXT (GLM)
|
|
## Coherence First, Less Choppy, Less Template Song
|
|
|
|
**Owner:** GLM via OpenCode
|
|
**Reviewer:** Codex
|
|
**Fecha:** 2026-04-02
|
|
**Baseline real:** `674195e90446`
|
|
**Estado actual:** `library-first-hybrid` funciona, pero auditivamente sigue `WEAK`
|
|
|
|
---
|
|
|
|
## 1. Runtime Truth
|
|
|
|
No cerrar este sprint con métricas cosméticas.
|
|
|
|
La sesión `674195e90446` confirma:
|
|
|
|
- `generation_mode = library-first-hybrid`
|
|
- `mandatory_midi_hook.materialized = true`
|
|
- `coherence_score = 4.7`
|
|
- `coherence_verdict = WEAK`
|
|
- `family_adherence_rate = 0.5`
|
|
- `piano_presence.has_piano = true` pero era casi todo por hook MIDI
|
|
- `repetition_metrics.verdict = mixed`
|
|
- `music_source_reuse_ratio = 0.8`
|
|
|
|
Conclusión:
|
|
|
|
- el sistema ya no está roto
|
|
- el problema ahora es musical y de planificación
|
|
- la canción sigue sonando demasiado segmentada, demasiado rígida y demasiado parecida a sí misma
|
|
|
|
---
|
|
|
|
## 2. Code Review
|
|
|
|
### 2.1 Qué estaba mal en v0.1.25
|
|
|
|
1. `reference_listener.py`
|
|
Los roles loop armónicos todavía podían aceptar material desde carpetas `one shots`. Eso empuja plucks cortados y variantes choppy que rompen continuidad musical.
|
|
|
|
2. `reference_listener.py`
|
|
El piano estaba siendo contado casi sólo por el hook MIDI. Eso permitía un falso positivo de `piano_presence` sin una capa audio real de keys/rhodes sosteniendo intro/build/break.
|
|
|
|
3. `reference_listener.py`
|
|
El bajo podía quedar sin anclas suficientes en `build/drop`, dejando huecos grandes aunque el rol estuviera “seleccionado”.
|
|
|
|
4. `reference_listener.py`
|
|
La extracción de packs seguía aceptando carpetas genéricas del workspace como si fueran packs reales. Eso inflaba o contaminaba la lectura de coherencia.
|
|
|
|
5. `song_generator.py` + `reference_listener.py`
|
|
La macro-estructura sigue demasiado determinística. No está “rota”, pero sí demasiado rígida:
|
|
`intro -> build -> drop -> break -> drop -> outro`
|
|
con reglas de entrada/salida muy parecidas entre corridas.
|
|
|
|
### 2.2 Qué ya corrigió Codex antes de este sprint
|
|
|
|
- rechazo de `one shots` para roles loop (`synth_loop`, `bass_loop`, `perc_loop`, `top_loop`, `vocal_loop`)
|
|
- inyección de una capa audio real de piano/keys cuando el sistema sólo tenía hook MIDI
|
|
- anclas mínimas de bass en `build/drop`
|
|
- limpieza adicional de extracción de pack para no tomar carpetas genéricas del workspace
|
|
|
|
Eso ya está en código. No lo rehagas ni lo reviertas.
|
|
|
|
---
|
|
|
|
## 3. Objetivo Real de v0.1.26
|
|
|
|
Recuperar **coherencia + musicalidad + estructura usable** sin volver al caos.
|
|
|
|
La salida buscada no es:
|
|
|
|
- una pista vacía
|
|
- una pista hiper-cortada
|
|
- una pista que repite 3 sonidos todo el tema
|
|
- una pista “ordenada” pero muerta
|
|
|
|
La salida buscada sí es:
|
|
|
|
- estructura clara
|
|
- identidad coherente
|
|
- más continuidad musical entre secciones
|
|
- más vida interna dentro de esa estructura
|
|
- audio piano/keys real, no sólo hook MIDI
|
|
|
|
---
|
|
|
|
## 4. Trabajo Obligatorio
|
|
|
|
### P0. Romper el “same song syndrome” sin romper coherencia
|
|
|
|
Atacar el problema en el path activo, no con métricas inventadas.
|
|
|
|
Objetivo:
|
|
|
|
- que dos generaciones consecutivas con misma referencia no caigan en la misma silueta exacta de densidad y capas
|
|
- que `intro/build/drop/break/drop/outro` no suene siempre al mismo guion mecánico
|
|
|
|
Reglas:
|
|
|
|
- no agregues randomización ciega
|
|
- la variación tiene que ser controlada por sección y por rol
|
|
- no mezcles packs sin función clara sólo para “diversificar”
|
|
|
|
Implementación esperada:
|
|
|
|
- introducir variación real de densidad por sección en `music bus`
|
|
- desacoplar parcialmente el patrón de entrada de `synth_loop`, `top_loop` y `perc_loop`
|
|
- evitar que `drop A` y `drop B` sean casi el mismo bloque con mínimos cambios cosméticos
|
|
|
|
### P0. Menos cortes, menos huecos muertos
|
|
|
|
El reggaeton actual está demasiado “picado”.
|
|
|
|
Problema audible:
|
|
|
|
- cortes bruscos
|
|
- demasiados espacios donde debería seguir el groove
|
|
- layers que entran una vez y desaparecen
|
|
|
|
Objetivo:
|
|
|
|
- continuidad rítmica y armónica mejor sostenida
|
|
- sin convertir todo en una pared constante
|
|
|
|
Validar especialmente:
|
|
|
|
- `bass_loop`
|
|
- `perc_loop`
|
|
- `top_loop`
|
|
- `synth_loop`
|
|
- `AUDIO KEYS SUPPORT`
|
|
|
|
No aceptes:
|
|
|
|
- capas musicales con 1 o 2 placements en toda la canción salvo justificación muy clara
|
|
- drops donde el bajo no sostiene el cuerpo principal
|
|
- breaks vacíos por accidente
|
|
|
|
### P0. Piano audio real, no sólo “piano_presence” de manifest
|
|
|
|
Nuevo estándar:
|
|
|
|
- `piano_presence.has_audio_piano = true`
|
|
- al menos una capa audio `piano/keys/rhodes` real en `intro`, `build` o `break`
|
|
- el hook MIDI puede seguir existiendo, pero ya no alcanza por sí solo
|
|
|
|
Qué buscar:
|
|
|
|
- `rhodes`
|
|
- `keys`
|
|
- `piano`
|
|
- `epiano`
|
|
|
|
Qué no hacer:
|
|
|
|
- meter piano brillante arriba de todo el drop si rompe el ancla principal
|
|
- reemplazar el primary family del tema
|
|
|
|
La regla musical es:
|
|
|
|
- `pluck/lead` puede seguir siendo la identidad principal
|
|
- `piano/keys` tiene que funcionar como soporte coherente, no como parche decorativo
|
|
|
|
### P1. Más riqueza tímbrica sin perder identidad
|
|
|
|
El sistema se encierra en 3-4 sonidos.
|
|
|
|
Necesitamos:
|
|
|
|
- más contraste útil
|
|
- menos reciclado del mismo material
|
|
- sin abrir demasiados packs
|
|
|
|
Objetivo:
|
|
|
|
- 1 pack dominante por bus
|
|
- 1 secundario sólo si tiene función clara
|
|
- más de un color musical dentro del bus music
|
|
|
|
No aceptes:
|
|
|
|
- `music_source_reuse_ratio >= 0.8`
|
|
- `synth_loop` y `synth_peak` sonando como el mismo gesto todo el tema
|
|
- variantes que sólo cambian filename pero no función musical
|
|
|
|
### P1. Coherencia, no plantilla rígida
|
|
|
|
La crítica del usuario es correcta:
|
|
|
|
- quiere estructura
|
|
- no quiere escuchar siempre la misma canción
|
|
|
|
Eso significa:
|
|
|
|
- no eliminar la estructura
|
|
- sí hacer que cada sección tenga una función musical real
|
|
|
|
Ejemplos de función real:
|
|
|
|
- intro: presentación y espacio
|
|
- build: empuje y preparación
|
|
- drop A: statement principal
|
|
- break: respiro con soporte armónico útil
|
|
- drop B: regreso con diferencia perceptible
|
|
- outro: salida lógica
|
|
|
|
---
|
|
|
|
## 5. Restricciones
|
|
|
|
### No tocar sin necesidad
|
|
|
|
- no reviertas fixes de Codex
|
|
- no reabras vocals automáticas
|
|
- no metas samples vocales “porque quedan bien”
|
|
- no vuelvas a permitir `one shots` como `synth_loop` por accidente
|
|
|
|
### No maquillar métricas
|
|
|
|
No cierres el sprint si:
|
|
|
|
- `coherence_score` sigue `WEAK`
|
|
- el audio sigue sonando vacío o excesivamente cortado
|
|
- el piano sigue siendo sólo MIDI
|
|
- el report dice `SUCCESS` pero la canción sigue auditivamente pobre
|
|
|
|
### No usar el report como sustituto del manifest
|
|
|
|
Toda afirmación tiene que salir de:
|
|
|
|
- `generation_manifests.json`
|
|
- manifest nuevo persistido
|
|
- session id real
|
|
- validación audible del resultado
|
|
|
|
---
|
|
|
|
## 6. Criterios de Salida
|
|
|
|
Para considerar este sprint cerrado, el nuevo manifest debe cumplir:
|
|
|
|
- `generation_mode = library-first-hybrid`
|
|
- `mandatory_midi_hook.materialized = true`
|
|
- `piano_presence.has_audio_piano = true`
|
|
- `piano_presence.audio_piano_count >= 1`
|
|
- `coherence_score >= 6.0`
|
|
- `family_adherence_rate >= 0.65`
|
|
- `pack_coherence.overall >= 0.6`
|
|
- `repetition_metrics.verdict != repetitive`
|
|
- `music_source_reuse_ratio < 0.7`
|
|
- `vocal_layers_auto = 0`
|
|
|
|
Y además, auditivamente:
|
|
|
|
- no debe sonar “trozada”
|
|
- no debe sonar como 3 sonidos repitiéndose toda la pista
|
|
- `drop B` debe diferenciarse de `drop A`
|
|
- `break` debe tener función musical y no ser sólo vacío
|
|
|
|
---
|
|
|
|
## 7. Validación Obligatoria
|
|
|
|
### Código
|
|
|
|
- `python -m py_compile` sobre archivos tocados
|
|
- `tests/test_piano_forward.py`
|
|
- `tests/test_selection_coherence.py`
|
|
|
|
### Runtime
|
|
|
|
Generar una sesión nueva real con referencia:
|
|
|
|
- género: `reggaeton`
|
|
- estilo: `perreo duro vieja escuela tipo safaera`
|
|
- referencia: `libreria\\reggaeton\\ejemplo.mp3`
|
|
- bpm: `95`
|
|
- key: `Am`
|
|
|
|
### Revisión del manifest
|
|
|
|
Reportar explícitamente:
|
|
|
|
- `session_id`
|
|
- `coherence_score`
|
|
- `family_adherence_rate`
|
|
- `pack_coherence.overall`
|
|
- `pack_coherence.music`
|
|
- `piano_presence`
|
|
- `repetition_metrics`
|
|
- `audio_layers` por rol
|
|
- qué layer de audio hace el soporte piano/keys
|
|
- diferencia real entre `drop A` y `drop B`
|
|
|
|
---
|
|
|
|
## 8. Formato del Validation Report
|
|
|
|
Crear:
|
|
|
|
- `docs/SPRINT_v0.1.26_VALIDATION_REPORT.md`
|
|
|
|
Estructura obligatoria:
|
|
|
|
1. `Runtime Truth`
|
|
2. `Manifest Evidence`
|
|
3. `Audible Outcome`
|
|
4. `Code Changes`
|
|
5. `Open Bugs`
|
|
6. `Verdict`
|
|
|
|
Reglas:
|
|
|
|
- no uses `SPRINT CERRADO CON ÉXITO` si `coherence_score` sigue en `WEAK`
|
|
- no ocultes métricas malas
|
|
- no digas “piano presente” si sigue siendo sólo hook MIDI
|
|
- si el audio sigue muy cortado o muy parecido a la corrida anterior, escribirlo explícitamente
|
|
|
|
---
|
|
|
|
## 9. Resumen para GLM
|
|
|
|
Tu trabajo no es “hacer más variación”.
|
|
|
|
Tu trabajo es este:
|
|
|
|
- conservar coherencia
|
|
- reducir lo choppy
|
|
- recuperar musicalidad
|
|
- meter piano audio real
|
|
- evitar la sensación de “misma canción siempre”
|
|
- no reabrir vocals
|
|
|
|
Si la nueva corrida sigue sonando rígida, vacía o demasiado loopeada, el sprint no está cerrado.
|