Jog displays y pantallas: qué se puede mapear y qué no

Hay una pregunta que aparece en todos los foros de mapping tarde o temprano: «mi controladora funciona, pero la pantalla del jog no hace nada; ¿cómo la mapeo?».

La respuesta corta es que no se mapea. Y la respuesta larga es más interesante, porque explica dónde está exactamente la frontera entre lo que un mapping puede hacer y lo que exige algo distinto.

Qué muestra la pantalla del jog

Conviene empezar sabiendo qué información vive ahí, para entender por qué no cabe en MIDI.

En la documentación oficial del CDJ-3000, la pantalla central del jog muestra la posición del playhead y la portada de la pista cargada, como recordatorio visual rápido. En controladoras suele añadirse la onda, el BPM y el tiempo restante.

Fíjate en la naturaleza de esa información: no son estados que cambian de vez en cuando, como un botón de loop. Son datos que se refrescan continuamente mientras suena la música. La onda se desplaza, el tiempo baja, el playhead avanza.

Ese detalle es la clave de todo lo que viene después.

Por qué el MIDI no llega hasta ahí

Dos razones, y las dos son estructurales:

1. Ancho de banda. MIDI está pensado para mensajes cortos y esporádicos: «se ha pulsado un botón», «esta perilla se ha movido». Una onda en tiempo real exige un refresco constante, y eso no es lo que el protocolo hace bien. La documentación de VirtualDJ lo dice al explicar qué aporta HID: permite pantallas LCD extensas con líneas de texto sin los problemas de ancho de banda habituales de MIDI.
2. El modelo de comunicación. En MIDI el controlador fuerza los mensajes aunque la aplicación no esté lista para procesarlos. En HID, el software pide los datos cuando puede atenderlos. Para un refresco continuo, el segundo modelo es el único sensato.

Y hay una tercera razón, más sutil, que aparece cuando miras cómo se ve esto desde dentro de un software: en la tabla de mapping de Traktor, los elementos ricos del equipo no aparecen como números que puedas escribir, sino como nombres de control —la documentación pone ejemplos como Left.Jog.Encoder— porque el dispositivo habla el protocolo propio del fabricante o HID.

Es decir: no es solo que el MIDI no llegue. Es que esos elementos ni siquiera se presentan como mensajes MIDI.

Qué se puede mapear por MIDI y qué exige protocolo aparte

La tabla deja la frontera clara. Y es una frontera amable: lo de arriba funciona igual aunque las pantallas estén apagadas. Por eso un controlador que «va a medias» suele ser, en realidad, un controlador completo al que le falta su capa HID.

El caso que lo demuestra, con nombre y apellidos

Existe un proyecto comunitario sobre la DDJ-FLX10 que documenta esto mejor que ninguna teoría. Y lo primero que dice es demoledor:

La configuración solo con MIDI te da un controlador completamente funcional. Esta extensión añade las pantallas del jog, que vienen «de serie» con Serato o rekordbox.

Ahí está todo. El MIDI te da el controlador entero. Las pantallas no son «una parte que falta por mapear»: son otra capa, y es la capa que el software oficial del fabricante da por hecha porque tiene acceso a información que tú no tienes.

Qué hace cada parte

El proyecto separa el trabajo en dos piezas, y el reparto es muy instructivo:

El mapping MIDI se encarga de botones, LEDs, rotación del jog y efectos. Es decir, todo lo que ya sabías mapear. Pero además hace una cosa que no es un mapping: un handshake SysEx —un intercambio de mensajes de sistema exclusivo— que desbloquea la pantalla HID.

La capa HID lleva la pantalla. Un script envía cada 100 ms un paquete de estado con la posición del playhead, el tiempo restante y el BPM. Y un proceso auxiliar en Python hace el trabajo pesado: abre el dispositivo hidraw, lee los análisis de onda que el software ya tiene calculados, los convierte al formato de onda propio del fabricante y los sube al equipo, con un goteo periódico que mantiene vivo el búfer de onda del firmware.

Por qué hacen falta las dos piezas

Aquí está el detalle técnico más valioso de la guía, y explica por qué esto no se resuelve con un mapping por muy elaborado que sea.

El entorno de scripting de un software de DJ no puede:

• Leer ficheros binarios (los análisis de onda están comprimidos y en un formato propio).
• Descomprimir datos.
• Abrir endpoints USB con informes HID de tamaño arbitrario.

Ninguna de esas tres cosas es un capricho del programa: son límites del entorno en el que corre un script de mapping. Y las tres son necesarias para pintar una onda en una pantalla ajena.

Por eso hace falta un proceso aparte, con permisos elevados, fuera del software. Un mapping no puede salir de su caja.

Antes de intentarlo: qué implica el desbloqueo

Los proyectos de este tipo incluyen un paso que se llama desbloqueo del fabricante, y es lo que habilita la interfaz de pantalla, que de otro modo permanece cerrada.

No voy a explicar cómo se hace, y no es un descuido: la regla editorial de este bloque dice expresamente que en el terreno del acceso a interfaces cerradas se explica la arquitectura, el contexto y los riesgos, sin publicar instrucciones de evasión ni claves. Me parece la postura correcta, y además es la útil: lo que decide si esto te conviene no es el procedimiento, es lo que implica.

Lo que implica, según la propia documentación del proyecto:

• Exige permisos elevados. El proceso auxiliar necesita acceso al dispositivo a bajo nivel.
• Se repite en cada conexión del equipo. No es una configuración que hagas una vez: cada vez que enchufas, toca repetirlo.
• Requiere el software en modo desarrollador.
• Añade piezas que pueden fallar. Un mapping que va mal se arregla; un proceso en segundo plano que se cae en mitad de un bolo, no.
• Y está fuera de toda garantía y soporte. No es una función documentada como soportada: es un proyecto de interoperabilidad hecho por la comunidad.

Ese es el balance real. Para un laboratorio o para entender cómo funciona tu equipo por dentro, es fascinante. Para pinchar, son demasiadas piezas.

Qué esperar según el programa

Un resumen honesto, porque las expectativas se forman mal en este tema:

• Con el software oficial del fabricante: las pantallas funcionan y no haces nada. Están cubiertas por el protocolo propio, y ese es el motivo por el que «vienen de serie».
• Con otro software, por MIDI: tendrás el controlador completo y las pantallas apagadas. Botones, LEDs, jog, efectos. Todo menos la información visual.
• Con otro software, por HID nativo: depende de si ese software soporta el modelo concreto. Cuando lo soporta, es la vía limpia, sin proceso auxiliar.
• Con otro software, por HID con desbloqueo: es el caso del proyecto de la FLX10. Funciona, y es un ejercicio de interoperabilidad, no una solución de cabina.

Y el dato que cierra el debate por el lado del fabricante: Serato deja el Numark Dashboard —un dispositivo de pantallas— en la lista de accesorios que no se pueden remapear en absoluto. Cuando el propio fabricante excluye del mapping justo el producto cuya razón de ser es una pantalla, el mensaje es claro.

Errores frecuentes

• Buscar la pantalla en la lista de funciones asignables. No está ahí porque no viaja por MIDI.
• Concluir que el mapping está mal porque la pantalla está vacía. El mapping puede estar perfecto: lo que falta es otra capa.
• Confundir «no funciona» con «no se puede mapear». Funciona en el software oficial, y ese es el punto.
• Intentar refrescar una onda por MIDI. Es un problema de ancho de banda, no de esfuerzo.
• Montar un desbloqueo para un bolo. Un paso manual por conexión y un proceso en root no son un plan para una cabina.
• Dar por hecho que el soporte HID de tu software cubre tu modelo concreto. Se comprueba modelo por modelo, no por marca.

Siguiente paso

Con esto ya sabes dónde acaba el mapping y dónde empieza otra cosa: cuando el elemento no es un mensaje MIDI sino un protocolo, la única salida es entender ese protocolo. Y eso tiene nombre, tiene método y tiene reglas: es el reverse engineering del hardware de DJ, que es exactamente lo siguiente.