Mods persistentes y temporales: rollback y anti-brick.

Un mod no es una cosa sola: hay mods que mueren al apagar el equipo y mods que se quedan dentro para siempre. La pregunta útil no es «cuánto cambia», sino dónde vive el cambio, qué sobrevive a un reinicio y cómo vuelvo atrás. Esas tres respuestas deciden si un experimento se deshace en diez segundos o se convierte en un problema de semanas.

Esta guía continúa Riesgos reales de instalar firmware modificado, que ya separó un mapping de un firmware modificado. Aquí toca el terreno operativo: la distinción entre Persistente vs temporal, el ciclo de Rollback / recovery / anti-brick, lo que la comunidad puede mirar de Engine OS internals y por dónde se tocan las OLED/display controllers del equipo.

Persistente vs temporal: qué sobrevive a un reinicio

Persistente vs temporal no es una escala de calidad, es una pregunta de ubicación. El cambio temporal vive en la sesión: un script que carga la aplicación, una asignación que existe mientras el software está abierto, un proceso auxiliar en memoria. Se apaga el equipo o se cierra el programa y no queda nada. El cambio persistente escribe en el almacenamiento interno: sigue ahí después del reinicio, y también después del siguiente.

Ese es precisamente el motivo por el que la persistencia no es una virtud. Un mod temporal puede morir en mitad de un b2b y solo te cuesta volver a cargarlo; un mod persistente sobrevive a todo, incluido el día en que decides que ya no lo quieres. La reversibilidad, no la permanencia, es la propiedad que interesa.

El criterio práctico es de una línea: ¿qué hay que deshacer para volver atrás? Si basta con quitar un fichero de la tarjeta o borrar una asignación en el software, estás en el lado reversible. Si hace falta reescribir la zona de arranque con el actualizador oficial, estás en el lado persistente, y ahí la vuelta atrás depende de dos cosas que casi nadie guarda: la versión original exacta de tu equipo y un actualizador que acepte instalarla.

La tabla de esta sección ordena los cinco tipos por dónde viven, si sobreviven al reinicio, cómo se deshacen y qué riesgo deje el equipo inutilizado tienen. Mírala antes de decidir, porque la última columna es la que de verdad importa.

Rollback / recovery / anti-brick: la vuelta atrás

Rollback / recovery / anti-brick son tres palabras para el mismo miedo con distintos momentos del desastre.

Rollback es volver a un estado conocido y exige un trabajo previo que no se puede improvisar: anotar el modelo y la versión exacta del firmware, conservar el paquete original correspondiente a ese equipo y guardarlo en dos sitios sin conexión. Sin ese depósito, no hay rollback: hay una esperanza.

Recovery es lo que hace el equipo cuando toca volver a ponerse al día. La documentación oficial de Engine DJ OS describe tres vías de actualización, y cada una es también un camino de recuperación conocido: la vía inalámbrica disponible desde la versión 1.6.0 desde el panel de control, la aplicación instaladora que habla con el equipo por cable USB, y el fichero .img colocado en la raíz de una unidad exFAT o FAT32 que el equipo lee por su cuenta. En todas se pide lo mismo: desenchufar los periféricos antes de empezar, esperar a que aparezca el mensaje de que el equipo se está actualizando y no lo apagues, y dar después un apagado y un encendido manual.

Anti-brick es la disciplina que evita llegar al punto en que el equipo ya no arranca ni acepta nada. Tres reglas cubren la mayor parte de los casos:

1. Nunca cortar la energía durante una escritura. El mensaje «Do not power off» no es una sugerencia.
2. Nunca meter una tarjeta con un fichero de actualización dudoso. El propio fabricante avisa de que, al reiniciar en modo de actualización, si el equipo detecta un fichero en una unidad se actualizará desde ese fichero y no desde el ordenador. El equipo hace lo que encuentra, sin preguntar de quién es.
3. Nunca programar una actualización víspera de un directo. La ventana segura es la de la mesa de trabajo, con tiempo y con luz.

El brick no tiene gesto de rescate documentado para el usuario. Si el equipo queda inutilizado, el final es el servicio técnico, y ahí desaparecen a la vez la garantía y la paciencia. Por eso el anti-brick se practica antes, no después.

Engine OS internals: qué se puede mirar

Engine OS internals es la sección donde más se exagera. Empecemos por lo que dice el fabricante: Engine DJ OS es la plataforma de software embebido que da vida a ese hardware, y cada actualización le añade funciones nuevas —streaming sin ordenador, iluminación, análisis de música a bordo, Ableton LINK inalámbrico desde la versión 2.0— con la promesa explícita de seguir mejorando «al igual que el sistema operativo de tu ordenador». Esa frase tiene una consecuencia práctica inmediata: el comportamiento cambia entre versiones, y cualquier afirmación sin número de versión y fecha es un rumor.

Lo que la comunidad puede mirar está bien descrito por el proyecto Mixxx, que documenta la extracción de Engine OS desde un equipo comercial y la aparición de definiciones de mapeo asociadas a una lista de modelos. Dos conclusiones de ese trabajo merecen leerse completas: el entregable público acabó siendo un mapping, es decir, la capa segura que se instala en el ordenador sin tocar el aparato, y quedaron preguntas sin respuesta documentada que se resolvieron por prueba y error.

Es decir: los internos se observan, se describen y se citan. No se redistribuyen, no se afirma compatibilidad de nada y no se publica una receta que no haya sido verificada con versión y fecha. Lo que sí puedes hacer con rigor es documentar lo tuyo: qué versión tenía tu equipo, qué cambiaste, qué pasó después y cómo volviste atrás.

OLED/display controllers: pantallas dentro del equipo

Las pantallas de una cabina no son todas iguales. Arriba están los displays táctiles grandes, cuyo contenido define el software. Debajo, y ahí está lo que nos interesa, están las pantallas pequeñas y normalmente monocromas: el panel del centro del jog, los indicadores de estado, los displays de los controladores caseros.

Para las segundas existen display controllers concretos, y la comunidad tiene encima de la mesa una biblioteca de referencia: U8g2, una biblioteca gráfica monocroma para dispositivos embebidos que soporta una lista larga de controladores —SSD1305, SSD1306, SSD1309, SH1106, SH1107, ST7565, UC1611, entre muchos otros— y distingue dos modos: U8g2, con procedimientos gráficos y búfer en el microcontrolador, y U8x8, de solo texto sobre una rejilla de 8x8 píxeles que escribe directamente en la pantalla sin búfer. Si construyes un panel propio o un pie controller, ahí es donde se trabaja, a nivel de biblioteca y de controlador, sin modificar el firmware de nadie.

Tocar la pantalla que ya trae el equipo es otro asunto. El proyecto de mapeo del jog del DDJ-FLX10 para Mixxx ilustra el coste real: hace falta el modo desarrollador del software de DJ, permisos elevados para un proceso auxiliar y un desbloqueo del fabricante que hay que repetir en cada conexión, y el propio entorno de scripting no puede leer ficheros binarios, descomprimir ni abrir endpoints USB con informes de tamaño arbitrario. Ese es el techo. Por eso las mods de pantalla son las menos reversibles de todas: viven detrás de más cerraduras que cualquier otra parte del equipo. El terreno limpio, el que se explica a fondo, es el de Jog displays y mapping.

Qué se afirma y qué no

• Se afirma lo que está en la documentación oficial, con su versión y su fecha.
• Se describe lo observado: qué mandó el equipo, qué respondió, en qué versión.
• No se afirma compatibilidad de ningún mod sin modelo, versión de firmware y fecha de comprobación.
• No se redistribuye firmware propietario ni se publican instrucciones para saltarse una protección.
• No se da asesoramiento jurídico: las normas varían por país; la práctica de la comunidad es equipo propio con propósito de interoperabilidad.

Cómo reducir el riesgo

Antes de tocar nada: anota modelo y versión exacta, y guarda el paquete original en dos sitios sin conexión. Durante: un solo cambio por prueba, sin cortar energía, y con el equipo lejos del calendario de directos. Después: comprobar la versión que quedó instalada, dar el apagado y encendido manual que pide el fabricante y anotar el resultado, sea bueno o malo. Si una prueba no se puede repetir, no es una prueba; y si no puedes volver atrás, no era un experimento, era una apuesta.

Siguiente paso

Ya tienes el marco: persistente o temporal según dónde viva el cambio, un rollback que depende de haber guardado la versión original, un anti-brick hecho de tres reglas simples y una idea clara de hasta dónde se puede mirar dentro de Engine OS y de las pantallas. El paso siguiente es entrar en la capa visible: cómo se documenta y se controla la pantalla del jog dentro del mapping, en Jog displays y mapping. Los riesgos de fondo que hacen falta aquí los encontrarás en Riesgos reales de instalar firmware modificado, y el método para mirar un protocolo sin tocar el equipo, en Reverse engineering de una controladora DJ.