Sync: Complete project state with all MEGA SPRINT V1-V3 features and Codex stubs
This commit is contained in:
renato97
335
docs/SPRINT_v0.1.26_NEXT_GLM.md
Normal file
335
docs/SPRINT_v0.1.26_NEXT_GLM.md
Normal file
@@ -0,0 +1,335 @@
|
||||
# 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.
|
||||
Reference in New Issue
Block a user