110 lines
3.5 KiB
Markdown
110 lines
3.5 KiB
Markdown
# Sprint v0.1.7 Next
|
|
|
|
Fecha: `2026-03-30`
|
|
|
|
Objetivo del sprint: dejar de generar “sonidos sueltos” y empezar a generar un track que conserve identidad melodica, armonica y timbrica durante toda la cancion.
|
|
|
|
## Contexto obligatorio
|
|
|
|
Antes de tocar codigo, leer:
|
|
|
|
1. `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\REFERENCE_TRACK_EJEMPLO_ANALYSIS.md`
|
|
2. `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\docs\ANTHROPIC_COMPAT_PROVIDER_CHECK_2026-03-30.md`
|
|
3. `C:\ProgramData\Ableton\Live 12 Suite\Resources\MIDI Remote Scripts\KIMI_K2_ACTIVE_HANDOFF.md`
|
|
|
|
## Estado de partida verificado por Codex
|
|
|
|
- `pack_brain` ya puntua palettes y ahora debe castigar conflictos armonicos `bass/music`
|
|
- `server.py` ya persiste `musical_theme` en manifest
|
|
- `coherence_analyzer.py` ya no debe contar el budget por suma bruta de tracks duplicados
|
|
- `ejemplo.mp3` muestra un contrato real:
|
|
- repeticion alta
|
|
- centro tonal estable
|
|
- low-end dominante
|
|
- pocas familias sonoras
|
|
- cambios por energia y brillo, no por randomizacion de layers
|
|
|
|
## Problema principal a resolver
|
|
|
|
El sistema todavia puede generar un track con:
|
|
|
|
- demasiadas capas opcionales
|
|
- bajo y material musical compatibles “en papel” pero flojos como cancion
|
|
- secciones que cambian demasiado de mundo sonoro
|
|
- hooks que no se perciben como una misma idea
|
|
|
|
## Trabajo del sprint
|
|
|
|
### 1. Theme persistence real
|
|
|
|
- Verificar que `musical_theme` no solo exista en `config`, sino que gobierne de verdad:
|
|
- `bass`
|
|
- `chords/pad`
|
|
- `lead/pluck`
|
|
- Si algun rol melodico importante se genera por fuera del tema, corregirlo.
|
|
- Dejar evidencia en manifest y logs.
|
|
|
|
### 2. Hook-family scoring
|
|
|
|
- Crear un score adicional que premie:
|
|
- reuso de contorno melodico
|
|
- reuso de ritmo del motivo
|
|
- misma familia tonal entre secciones
|
|
- Penalizar si `lead/pluck/chords` parecen venir de ideas distintas.
|
|
|
|
### 3. Section coherence hardening
|
|
|
|
- Cada seccion debe ser una variacion del mismo track, no otro track.
|
|
- Para `intro/build/drop/break/outro`, limitar cambios a:
|
|
- densidad
|
|
- brillo
|
|
- cantidad de capas activas
|
|
- version del mismo motivo
|
|
- No permitir que `break` u `outro` cambien a una palette incompatible.
|
|
|
|
### 4. Audio-layer sanity
|
|
|
|
- Auditar por que se materializan demasiadas capas similares.
|
|
- Detectar y evitar:
|
|
- duplicados MIDI/audio de la misma funcion sin necesidad
|
|
- `perc_main` y `perc_alt` con el mismo archivo
|
|
- varios layers vocales/fx que no agregan contraste real
|
|
|
|
### 5. Reference-fit report
|
|
|
|
- Crear un reporte de comparacion contra `ejemplo.mp3` con al menos:
|
|
- BPM
|
|
- key
|
|
- low/mid/high ratio
|
|
- RMS envelope general
|
|
- onset density
|
|
- motif reuse / recurrence proxy
|
|
- budget por slots logicos
|
|
- Ese reporte debe decir `closer` o `farther` respecto al intento anterior.
|
|
|
|
## Aceptacion minima
|
|
|
|
No cerrar el sprint sin esto:
|
|
|
|
1. una generacion nueva en Live
|
|
2. manifest guardado con `musical_theme`
|
|
3. coherence report sin conteo bruto inflado
|
|
4. sin conflicto armonico claro entre `bass` y `music`
|
|
5. una nota honesta de escucha tecnica sobre si el resultado ya se parece mas a `ejemplo.mp3`
|
|
|
|
## No hacer en este sprint
|
|
|
|
- no abrir otra integracion nueva de modelos si el problema sigue siendo musical
|
|
- no agregar mas capas “para llenar”
|
|
- no declarar exito por compilacion
|
|
- no declarar exito porque el job async crea tracks
|
|
|
|
## Si Z.ai falla
|
|
|
|
Fallback preferido:
|
|
|
|
1. `glm-5 @ DashScope`
|
|
2. `qwen3.5-plus @ DashScope`
|
|
|
|
No usar `Fireworks / kimi-k2p5-turbo` como arbitro principal mientras siga obedeciendo peor el contrato simple de salida.
|