LivingMusic

No estaba buscando un proyecto nuevo. Todo empezó después de ver varios videos del Cotodama Lyric Speaker — la tipografía dejaba de ser un simple texto para convertirse en parte de la música. Las palabras aparecían, respiraban y desaparecían siguiendo el ritmo de cada canción. Era una experiencia visual, no un karaoke. Después de buscar encontré muchos reproductores con letras sincronizadas, pero ninguno trataba la tipografía como el elemento principal de la experiencia. Todos resolvían el problema de leer una canción. Yo estaba buscando sentirla desde otro lugar. Apareció una pregunta bastante sencilla: si la aplicación que quiero no existe, ¿por qué no construir una versión pequeña para entender cómo funciona? Ese fue el verdadero inicio de LivingMusic. No quería competir con Spotify ni construir otro reproductor — lo que me interesaba era explorar qué ocurre cuando la tipografía también interpreta la canción.

Pensé que la parte más sencilla sería obtener las letras sincronizadas. Después de investigar descubrí que era exactamente al revés. Spotify y Apple Music no exponen letras sincronizadas mediante sus APIs públicas. Las soluciones abiertas suelen ofrecer sincronización por línea — suficiente para un karaoke tradicional, pero insuficiente para el tipo de experiencia que imaginaba. Musixmatch sí dispone de sincronización mucho más precisa, incluso por palabra, pero esa funcionalidad pertenece a acuerdos comerciales orientados a grandes empresas. La decisión fue cambiar de estrategia: el MVP trabajará con un pequeño catálogo de canciones cuidadosamente preparadas, usando LRCLIB como fuente abierta y forced alignment casero para timestamps por palabra. A veces la mejor decisión no consiste en encontrar una solución más compleja, sino en reducir el alcance hasta recuperar el control del problema.

La primera versión del proyecto asumía que Spotify y Apple Music serían el punto de partida. Después de entender las limitaciones de las APIs esa idea dejó de tener sentido. LivingMusic no necesita conectarse a un servicio de streaming para demostrar su propuesta de valor — necesita demostrar que una canción puede adquirir una identidad visual propia. El MVP trabajará únicamente con un pequeño catálogo local. Si la experiencia funciona con cinco canciones, más adelante podrá crecer. Si no funciona con cinco, tampoco funcionará con cinco millones. Era fácil caer en la tentación de construir primero la infraestructura. Preferí validar primero la experiencia.

Muy pronto apareció una decisión que terminó definiendo todo el proyecto: no quería un único estilo visual para todas las canciones. Una balada no comunica lo mismo que un rap. Una pieza instrumental no transmite el mismo ritmo que una canción electrónica. La interfaz debía adaptarse a la música y no al revés. Por eso cada canción tendrá un preset de dirección artística donde la tipografía, la composición, el movimiento y el ritmo podrán cambiar completamente. La consistencia no vendrá de repetir animaciones — vendrá de compartir una misma filosofía de diseño. Si la música cambia de personalidad en cada canción, la interfaz también debería tener permiso para hacerlo.

La máquina principal de desarrollo es Windows. iOS y Apple TV requieren macOS y Xcode — un requisito duro de Apple sin workaround real. Se confirmó que hay una Mac disponible para cuando toque compilar y probar ese frente, así que el alcance de cuatro plataformas (iOS, Android, Apple TV, Android TV) se mantiene. No es un bloqueo, sino una restricción que hay que tener en cuenta desde el principio. El desarrollo día a día avanza en Windows; las pruebas de plataformas Apple van a la Mac cuando haga falta.

El scaffold del proyecto quedó en commit f912b84 usando @react-native-tvos/template-tv (React Native 0.86, React 19.2, TypeScript 5.8). Inmediatamente después se intentó el primer build en Android. El CLI de React Native falló al invocar gradlew.bat — un bug conocido de Windows con subprocesos .bat. Se resolvió invocando Gradle directamente, pero entonces apareció un segundo problema: conflicto entre Gradle 9.0.0 (recién liberado, viene incluido en el template) y el plugin de resolución de toolchains JDK (IBM_SEMERU). Se decidió no perseguir ese problema de inmediato y explorar una ruta alternativa para validar el motor visual sin depender del emulador nativo.

El desarrollo comenzó en React Native puro. Muy pronto apareció una fricción real: cada prueba dependía de levantar un emulador, esperar compilaciones y repetir un ciclo demasiado lento para un proyecto que probablemente exigirá cientos de pequeños ajustes visuales. La investigación confirmó que react-native-skia tiene soporte web maduro vía CanvasKit (WASM) — el mismo motor Skia, no una aproximación. Se creó un monorepo con tres paquetes: packages/engine (lógica compartida), apps/mobile (el proyecto RN+tvOS) y apps/web-preview (Vite + React + Skia web). La intención nunca fue construir una versión web del producto. El objetivo era disponer de un laboratorio donde cualquier cambio pudiera verse casi al instante. Cuando el ciclo entre una idea y su validación dura demasiado, también disminuye la curiosidad por seguir experimentando.

Después de varias decisiones de arquitectura apareció una pregunta mucho más importante: ¿realmente funciona esta idea? En lugar de integrar audio, streaming y sincronización real se construyó primero una prueba mínima — un reloj. Si el motor podía animar correctamente una frase utilizando únicamente el paso del tiempo, después podría hacerlo siguiendo una canción real. packages/engine recibió sus primeras piezas reales: types.ts (LyricWord) y sync.ts (computeWordEmphasis, función pura que calcula una curva de énfasis 0→1 por palabra con rampas de entrada y salida). La primera implementación del proyecto no reproduce música. Solo intenta demostrar que las palabras pueden moverse con intención. El verdadero producto no es el reproductor — es el motor visual. Todo lo demás puede construirse después.

Durante varias horas se asumió que el motor estaba funcionando. Los procesos terminaban correctamente, las respuestas HTTP eran exitosas, nada parecía indicar un problema. Hasta que se abrió el navegador: no había absolutamente nada. Ese momento obligó a revisar cada supuesto desde el principio. La cadena de causas fue larga — dependencias CJS de react-native-web sin pre-bundling explícito, shims faltantes para TurboModuleRegistry, la versión de canvaskit-wasm (^0.40.0) desalineada con la que react-native-skia empaqueta internamente (0.41.0 exacto), y extensiones .web.js que esbuild ignoraba mientras Metro las resuelve correctamente. Más importante que corregirlas fue entender otra cosa: se había dado por válida una hipótesis sin comprobar el resultado final. Las herramientas pueden decir que todo salió bien. El usuario siempre tiene la última palabra. En un proyecto visual, esa última palabra empieza cuando realmente aparece algo en la pantalla.

Después de varios intentos el motor consiguió renderizar su primera frase utilizando el Sync Engine y Skia — commit 6ef51a8. No había audio, no existía un reproductor, tampoco un sistema completo de animaciones. Solo una frase, un reloj y un conjunto de cálculos que controlaban el énfasis de cada palabra. Era una prueba muy pequeña. Pero por primera vez el proyecto dejó de ser una arquitectura dibujada sobre papel y empezó a comportarse como aquello que imaginé cuando vi aquellas primeras animaciones tipográficas. Los grandes hitos rara vez llegan con una interfaz terminada. A veces llegan cuando una sola palabra aparece exactamente donde esperabas verla.

Antes de escribir una sola línea de código de animación necesito saber con qué cuerpo van a moverse las palabras. No sirve cualquier fuente — necesito un set de tipografías libres que tengan carácter propio, que puedan cargar con el peso emocional de una canción sin romperse. Entre cinco y diez. Que cubran el espectro sin solaparse: la que se siente fría y estructural, la que se siente humana y cálida, la que tiene rotura, la que es perfectamente geométrica, la que respira. Una paleta. Porque si cada canción va a tener su propia dirección artística, las tipografías son la primera decisión de esa dirección — antes del movimiento, antes del ritmo, antes de todo. No puedo llegar al momento de diseñar para una canción y empezar a buscar. El cajón tiene que estar lleno antes.

Tenía pensado entrenar el motor mirando videos — estudiar cómo se mueven las palabras en referencias que me gustan, extraer patrones, replicarlos. Pero mientras lo pensaba me di cuenta de que era exactamente lo que no quería hacer. Si el motor aprende de referencias, siempre va a ser una copia sofisticada. La palabra tiene que sentirse, no parecerse a algo que ya vi. Cambié el plan. Primero el manifiesto. Antes de escribir código de animación, escribo las reglas de por qué una palabra se mueve de cierta manera — qué significa que una palabra "cargue peso", qué es el silencio tipográfico, por qué la velocidad de entrada y la de salida no tienen que ser iguales. Compartí las ideas con Claudio — así le llamo cuando estamos en modo creativo, no modo debug — y empezamos a iterar. Lo que está saliendo no es un manual técnico: es un catálogo reutilizable de primitivas de movimiento. El manifiesto es el índice. El código vendrá después, y cuando llegue ya sabrá para qué existe. Hay algo que me resulta muy familiar en todo esto. Estoy actuando como director de arte editorial de un medio que todavía no existe. Es exactamente el mismo proceso que cuando arrancaba en diseño publicitario — cuando el producto era papel, el movimiento era solo imaginado, y aun así tenías que tomar decisiones sobre él. Parece que vuelvo al mundo impreso, pero con un lienzo que respira.

Wonderwall. Oasis, 1995. Es la primera canción del catálogo LivingMusic. No la elegí por nostalgia — la elegí porque tiene exactamente el arco emocional que necesito para probar si el sistema funciona de verdad: incertidumbre → duda → tensión creciente → catarsis anthémica. Si el motor puede seguir ese arco, si las primitivas del manifiesto pueden acompañarlo sin forzarlo, puede acompañar cualquier arco. Si no puede, quiero saberlo ahora, con cinco letras de Oasis y no con un álbum completo de algo más complejo. Simulé cuatro frases aplicando el vocabulario completo — cómo entra cada palabra, qué peso carga, cuándo respira el layout, cómo escala la tensión antes del estribillo. Es la primera vez que el proyecto deja de ser un sistema abstracto y se convierte en algo que podría sentirse. Hasta ahora tenía un motor, un set de primitivas y un cajón de tipografías. Ahora tengo una canción real con un arco real. Y Wonderwall no pide ser leída — pide ser sentida desde la primera línea.

Después de elegir Wonderwall como primer caso de estudio empezamos a simular las cuatro frases del arco emocional aplicando el vocabulario del manifiesto. Lo que sigue es el acta de la sesión — las decisiones tomadas, las que rechacé y por qué. Frase 1. La sugerencia inicial fue Archive. La rechacé. Archive ya sabe lo que es — tiene presencia, tiene carácter definido, ocupa espacio. Wonderwall arranca antes de saber lo que es. Necesita una voz que todavía no confíe en sí misma. Voice. Horizon. Una tipografía que existiera en el límite entre aparecer y no estar todavía. Frase 2. Aquí sí. Whisper, Resistir, Papel — perfecto tal cual. Pero quiero agregar algo que no estaba en el vocabulario original: el papel no vuelve a su estado inicial después de plegarse. Hay una deformación que persiste aunque sea invisible. Eso tiene que estar en la animación: cuando aparezca la siguiente línea debería conservar algo de la anterior. Un residuo. Una pequeña distorsión. Porque la canción recuerda, aunque la letra no lo diga. Eso es cine. Frase 3. Discrepo con Machine. Machine implica precisión y Wonderwall nunca es precisa — es humana, irregular, imperfecta. Cambié la propuesta: Pulse. No es máquina, no es susurro. Es corazón. Late. Y donde había Metal propuse Materia Cuerda. La tensión de Wonderwall no es industrial. Es orgánica. Como una cuerda de guitarra que vibra después de ser pulsada y sigue vibrando más de lo que debería. Mucho más coherente con Oasis. Frase 4. El cambio más fuerte. Expandir no funciona — parece una recompensa, y Wonderwall nunca termina de resolver. El coro no dice "todo está bien". Dice "creo que eres tú". Todavía hay duda. Todavía hay pregunta. La frase tiene que crecer sin cerrar. Ese vocabulario está por definirse. Es la parte más difícil de traducir al sistema — y probablemente la más importante. Cuatro frases. El manifiesto está siendo puesto a prueba antes de estar terminado. Así es exactamente como debería funcionar.

El manifiesto como lista de primitivas tiene un problema que recién estoy viendo: es demasiado lineal. Demasiado PowerPoint. Define reglas pero no entiende por qué esas reglas existen. No tiene referencias, no tiene memoria visual, no tiene intuición. Es un índice sin cuerpo. Lo que necesito no es un manual — es un cerebro. Le compartí a Claudio capturas de estilo editorial de un video de Lewis Capaldi. No como referencia para copiar — como evidencia de que algo puede sentirse de una manera específica y hay que entender por qué. La tipografía en ese video no decora la música. La interpreta. Hay decisiones ahí que no están en ningún manual de motion design porque no vienen de reglas — vienen de sensibilidad. Así que estamos reestructurando. El cerebro de animaciones va a tener tres capas: referencias visuales con anotaciones (qué ocurre y por qué funciona), un catálogo de canciones con sus arcos emocionales mapeados, y encima de todo eso las primitivas — pero ahora con contexto, con ejemplos reales, con la pregunta de por qué esta primitiva y no otra. No sé si esto tiene nombre en ninguna metodología. Probablemente no. Pero es la diferencia entre un sistema que genera animaciones correctas y uno que genera animaciones que se sienten bien. Lo primero se puede documentar en un readme. Lo segundo necesita un cerebro.