Por qué replicar el estado del motor de luces es mala idea, qué hace mejor un espejo de trama, por qué la posición del espectáculo viaja aparte y por qué devolver el control se hace a mano.
El planteamiento suena sencillo: que haya un segundo ordenador y, si el primero muere, la luz no se apague.
Después empieza la ingeniería, y la primera decisión ya determina si tendrás un esquema que funciona o uno bonito que te deja tirado en el peor momento.
La idea obvia: sincronicemos el estado. Que la consola de respaldo tenga los mismos cues, los mismos efectos, la misma posición, y en el relevo simplemente siga calculando.
Es una trampa, y por esto.
Un motor de luces no es un almacén de valores, sino una máquina que recalcula la imagen en cada trama: efectos con sus fases, fundidos con sus tiempos, capas de listas de cues en paralelo, grand master. Para que el respaldo «simplemente siga», tiene que reproducir no los datos sino la fase de ejecución: en qué milisegundo va un fundido, en qué ángulo está el seno del arcoíris, qué capa pisa a cuál.
Sincronizar eso por red significa escribir un segundo motor de luces que vive dentro del protocolo. Y ese segundo motor se separará del primero sin remedio: aquí se pierde un paquete, allí un tick llega 3 ms tarde, y la diferencia se acumula justo hasta el momento en que hacía falta que no.
La trama resultante. La consola principal envía al respaldo su búfer de salida diez veces por segundo: exactamente los bytes que van a los aparatos. Ninguna mecánica, ninguna fase: la imagen tal cual.
El respaldo no la saca. Calla — ni un byte por USB ni por red — y simplemente recuerda la última trama. En el relevo la pone y sigue viviendo con su propia lógica.
El relevo sale honesto sin modelo compartido. El público ve exactamente la imagen que había una fracción de segundo antes de que muriera la principal, porque transferimos lo que ve el público y no aquello con lo que se calculó.
El latido va aparte, cuatro veces por segundo. Un silencio de más de dos segundos (ocho latidos perdidos) dispara el relevo. El umbral se configura, pero bajarlo de un segundo es imprudente: un pico de red durante una subida de contenido daría un falso positivo, y dos consolas escribiendo en la línea a la vez es peor que un segundo de retraso.
Ya transferimos la imagen. Pero imagina: la principal murió en el cue 47, el respaldo tomó el relevo, la luz es correcta. El operador pulsa GO — y cae en el cue 12, porque el respaldo llevaba toda la noche parado ahí.
Por eso, aparte de la imagen, viaja la posición del espectáculo: lista de cues activa y cue dentro de ella, grand master, blackout, freeze. Se aplica en el momento del relevo, y se aplica sin volver a lanzar el cue. La luz ya es correcta; relanzarlo regalaría un fundido de más delante del público.
Son dos flujos de datos distintos, honestamente separados: «qué hay en escena» y «dónde estamos en el espectáculo».
El error de principiante más común es meter una interfaz USB-DMX en cada ordenador y juntar ambas en una línea.
No se puede. RS-485 es un bus en el que habla exactamente un transmisor cada vez. Dos interfaces escribiendo a la vez pelean físicamente por el nivel del par trenzado; DMX512 no contempla arbitraje alguno. El resultado no es «gana el último», es basura en la línea y aparatos que dan tirones.
Sólo hay un esquema que funciona: ambas consolas sacan la luz por red (Art-Net o sACN) hacia nodos compartidos. El respaldo calla en la red, así que el nodo ve un único emisor: sin pelea y sin arbitraje.
Si aun así vas por USB, la redundancia sólo te da un reinicio manual rápido: sacar la interfaz del ordenador muerto y meterla en el vivo. También es un plan, pero hay que ensayarlo, no descubrirlo.
La principal ha revivido. El respaldo lo oye — el latido ha vuelto. Y no hace nada.
No hay devolución automática, y es deliberado. El momento en que la principal «ya está viva» pero todavía carga el proyecto o reabre la interfaz es indistinguible por red del momento en que está lista. La automatización devolvería el control en el primer segundo, y tendrías o un apagón o dos emisores a la vez.
Así que lo devuelve una persona: comprobado que la principal ha vuelto de verdad, pulsa «Devolver control» en el respaldo. Un botón, pero en un momento con sentido.
Los efectos en marcha y un fundido a medias no continúan tras el relevo. El respaldo toma la última trama tal cual, estática. Si la principal murió justo a mitad de un fundido de diez segundos, ese fundido no llega: la imagen se queda donde la pillaron.
Es consecuencia directa de «transferimos el resultado, no la mecánica», y no lo cambiaría: una imagen estática correcta es mejor que una dinámica desincronizada.
La posición del espectáculo sí se transfiere, así que el siguiente GO va adonde habría ido en la principal, y el fundido hacia ese cue corre normal.
El espejo de trama, por cierto, no se activa en montajes de más de 64 universos: ahí el tráfico crece más rápido que el beneficio. El latido sigue funcionando: el respaldo tomará el relevo, pero partiendo de su propia imagen.
El cuarto paso es el que más se salta la gente, y así se enteran del problema la noche en que la principal se cae de verdad.