Resucitar un mezclador de vídeo de los años 90 con tecnología web moderna suena a capricho de ingeniero, pero es exactamente el tipo de reto que revela cómo el software bien diseñado puede honrar el hardware sin pretender copiarlo. El Panasonic WJ-MX50 fue un equipo de sobremesa para edición A/B en S-VHS, con dos buses, 287 patrones de transición, clave de crominancia, memoria de ocho eventos y una palanca que los VJs de clubs techno convirtieron en instrumento musical visual. Ahora, gracias a WebGPU, TypeScript y una obsesión por el comportamiento original, ese instrumento vuelve a la vida en el navegador. Y en el proceso, deja lecciones que cualquier empresa de desarrollo de software debería escuchar.
El proyecto web-mx-50 no es un emulador al uso. No busca replicar cada píxel del circuito NTSC de 1992, porque los formatos de vídeo actuales ya no tienen entrelazado ni submuestreo cromático. En lugar de eso, reproduce el comportamiento observable del aparato: qué LED parpadea cuando pulsas un botón, cómo se comporta el joystick al aplicar el efecto mosaico, cuántos fotogramas dura un fundido cuando ajustas el control de Auto Take (de 0 a 510, en pasos de dos). Eso es lo que convierte un mezclador en un instrumento expresivo, y eso es exactamente lo que se ha llevado al mundo digital.
La arquitectura del proyecto es un ejemplo de cómo debería hacerse el desarrollo de aplicaciones a medida cuando la fidelidad al dominio importa. Todo arranca con el manual de usuario de Panasonic, 40 páginas que describen con precisión casi quirúrgica las transiciones de estado del panel. Ese manual se convirtió en el programa: no se escribió código hasta que las 536 historias de Gherkin (escritos en lenguaje natural) estuvieron listas para fallar en el test si el orden de los colores del matiz no coincidía con el documento original. Esa disciplina de especificación primero, código después, es la misma que aplicamos en Q2BSTUDIO cuando abordamos proyectos de automatización de procesos, inteligencia artificial o ciberseguridad: entender el comportamiento del sistema antes de tocar una línea de código.
El corazón del mezclador es un único valor JSON serializable que representa el estado completo del panel. Cada cambio pasa por un reducer puro, sin clases ni observables. Esto hace trivial la memoria de eventos: clonar el estado y guardarlo en uno de los ocho slots es una simple llamada a structuredClone. También facilita la persistencia en el navegador, el control remoto por MIDI o gamepad, y la integración con sistemas externos. En el fondo, es la misma filosofía que seguimos en nuestros servicios cloud en AWS y Azure: tener un único origen de verdad evita que los datos se dispersen y que las transiciones de estado se vuelvan frágiles.
La parte gráfica corre sobre WebGPU. Los 287 patrones de transición no son una lista gigante, sino un álgebra: siete familias, cada una con cuatro variantes, más modificadores apilables (compresión, diapositiva, múltiple, emparejamiento, persianas) y una tabla de legalidad. El shader de transición trata cada familia como un campo de distancia firmada analítica. Un solo shader, un bloque de uniformes, siete campos. La decisión de renderizar en espacio lineal (sRGB con corrección gamma) evita los oscurecimientos en los bordes de las transiciones, un problema que el hardware original no tenía porque su salida era analógica, pero que el software debe resolver explícitamente.
El tiempo es otro capítulo interesante. El MX50 original medía los fundidos en fotogramas de vídeo, no en milisegundos. El código actual utiliza un reloj lógico de paso fijo: un acumulador convierte el tiempo real en ticks de fotograma entero, y toda la lógica dependiente del tiempo lee solo esos ticks. Un fundido de 300 frames dura exactamente 300 ticks tanto en un monitor de 60 Hz como en uno de 144 Hz. Esto es crucial para los VJs que necesitan aterrizar una transición justo en el inicio de una frase musical. Y es también un ejemplo de cómo un sistema de información bien diseñado debe abstraer el tiempo real para garantizar determinismo, algo que aplicamos en proyectos de inteligencia artificial y agentes autónomos donde la sincronización entre eventos es crítica.
Uno de los aspectos más originales del proyecto es que no se intentó emular el circuito de sincronización de fotogramas (frame synchronizer) porque ese problema ya no existe en los flujos de vídeo modernos. En su lugar, se aprovecharon los efectos laterales que ese circuito generaba: los fotogramas almacenados por bus que permiten los modos Still, Strobe, Multi y Trail. Al compartir un único framebuffer por bus, las reglas de exclusión mutua (Still y Strobe no pueden estar activos a la vez; Trail se monta sobre Still) caen por su propio peso. Es un ejemplo de cómo entender las restricciones originales del hardware facilita el diseño del software.
Desde la perspectiva de una empresa como Q2BSTUDIO, este proyecto ilustra varias lecciones transferibles a cualquier desarrollo de software empresarial. La primera: la especificación debe ser ejecutable. El manual de Panasonic, transformado en escenarios Gherkin, actúa como test de regresión continuo. Cuando alguien modifica el código y rompe el orden de parpadeo de un LED, el test falla. Eso es exactamente lo que implementamos en nuestros servicios de Business Intelligence con Power BI: validar que los dashboards reflejan fielmente las reglas de negocio antes de desplegarlos. La segunda lección: la arquitectura de un solo estado serializable simplifica todas las funcionalidades que parecen complejas —memoria de eventos, persistencia, control remoto— y evita que el estado se fragmente en componentes. Esa misma arquitectura la aplicamos en sistemas de ciberseguridad donde cada acción debe ser auditada y reproducible.
El proyecto también toca temas de inteligencia artificial, aunque de forma indirecta. El panel del MX50 tiene ocho memorias de eventos que pueden ser programadas y luego disparadas con un solo botón. Eso es, en esencia, un sistema de automatización de secuencias visuales. En Q2BSTUDIO desarrollamos agentes de IA que toman decisiones secuenciales sobre datos en tiempo real, y la lógica de eventos del mezclador es un primo lejano de esos sistemas. La capacidad de mapear un controlador MIDI o un gamepad al mismo lenguaje de comandos que los botones físicos abre la puerta a interfaces de usuario alternativas, algo que investigamos en proyectos de automatización industrial.
El estado actual del proyecto es un prototipo completo y verificado, con 536 escenarios Gherkin y 208 tests unitarios convencionales. El código fuente está publicado en GitHub, y los próximos pasos incluyen un componente web que permita incrustar el mezclador en cualquier sitio, una interfaz que replique el panel original y soporte para múltiples pestañas y ventanas. También se explorará el uso del mezclador como herramienta para arte visual en tiempo real dentro de páginas web, combinándolo con fuentes de vídeo generadas por IA o con datos de sensores.
En definitiva, resucitar el Panasonic WJ-MX50 con WebGPU no es solo un homenaje a una pieza de hardware icónica. Es una demostración de cómo el software bien construido —con especificaciones ejecutables, estado único y abstracción del tiempo— puede capturar la esencia de un instrumento físico y trasladarlo a la web sin perder su expresividad. En Q2BSTUDIO aplicamos esa misma filosofía cada día, ya sea desarrollando aplicaciones a medida, desplegando infraestructura cloud, asegurando sistemas contra ciberataques o construyendo agentes de inteligencia artificial. Porque al final, lo que importa no es la tecnología, sino el comportamiento que esa tecnología permite.
