Cómo controlar LEDs y colores desde un mapping

Los LEDs son la parte del mapping que más se descuida y la que más cambia la experiencia. Un mapping con feedback de estado se maneja a oscuras; uno sin él te obliga a mirar la pantalla cada vez que dudas. La diferencia entre ambos no es hardware: es haber hecho las asignaciones de salida.

Y ahí está el primer malentendido que hay que deshacer: que un botón se ilumine no forma parte de la asignación del botón. Son dos mappings distintos.

Entrada y salida son dos mappings distintos

Un mapping tiene dos direcciones, y conviene pensarlas por separado:

• Entrada: lo que el equipo le dice al software. «Se ha pulsado este botón.» Decide qué hace la función.
• Salida: lo que el software le dice al equipo. «Enciende esta luz.» Decide qué se ve.

Por eso el síntoma es tan común y tan desconcertante: el botón funciona, pero no se ilumina. No es un fallo: es que la mitad del trabajo está hecha. La entrada está asignada y la salida no existe.

Existe incluso una consecuencia que ahorra tiempo en la diagnosis: como la salida es una asignación aparte, el LED puede estar iluminando mal sin que la función falle, y al revés.

Cómo se ilumina realmente un LED

Hay una convención que vale para casi todo el hardware y que explican las tres fuentes de esta guía:

Los botones suelen controlar su LED enviando un mensaje corto con los mismos dos primeros bytes que cuando el controlador envía la señal de que el botón se ha pulsado.

Dicho de forma práctica: si tu botón envía 0x91, 0x11, 0x7F al pulsarse, entonces:

• Enviar 0x91, 0x11, 0x7F enciende el LED.
• Enviar 0x91, 0x11, 0x00 lo apaga.

Es decir, el LED y el botón comparten «dirección». Lo único que cambia es quién manda el mensaje y con qué tercer byte.

El color: normalmente el tercer byte

Si el LED tiene varios colores, el color suele determinarlo el tercer byte. El mismo mensaje con un valor distinto da otro color.

Esa es la clave para no volverse loco: guarda los códigos de color en una tabla con nombre en lugar de repartir números por todo el código. En la práctica es la diferencia entre un mapping que puedes retocar en dos minutos y uno que no te atreves a tocar.

Dónde se activan los LEDs, según el software

Depende del programa, y cada uno lo llama distinto:

• rekordbox: la columna MIDI OUT es el código que se envía al equipo. Y hay un detalle cómodo: si la función incluye indicador, el mismo código del MIDI IN se envía automáticamente al MIDI OUT, así que en muchos casos el LED funciona sin que hagas nada. Existe además un tipo de control llamado Indicator, específico para mandar información de iluminación, con una particularidad importante: con ese tipo no puedes asignar la función operando el control, hay que escribir el código en MIDI OUT a mano.
• Traktor: hay una columna I/O que distingue entradas y salidas. Las salidas sirven para que el controlador visualice el estado del software y se ven como LEDs encendidos o parpadeando. Aquí hay una regla que conviene conocer: la asignación manual es la única forma de asignar un control de salida. No hay un «Learn» que te lo resuelva.
• Mixxx: se envía MIDI de vuelta al controlador desde el script, con una función para mensajes cortos y otra para SysEx.

El patrón se repite en todos: la salida es más manual que la entrada. Aprender moviendo el control solo funciona para la entrada.

El error que desincroniza todos los LEDs

Este es el consejo de diseño más valioso de toda la guía, y viene de la documentación de Mixxx:

No envíes los mensajes de LED directamente desde las funciones que manejan la entrada. Cambia el estado de un control del software y envía el MIDI desde un callback que reaccione a ese cambio.

La razón es contundente: si el LED refleja el estado real del software, el controlador se mantiene correcto aunque el usuario use el teclado, el ratón u otro controlador. Si en cambio lo enciendes porque «se ha pulsado el botón», el LED miente en cuanto el estado cambia por otra vía.

Piensa en un caso real: tienes un botón de loop y su LED. Si activas el loop con el ratón, un LED que solo reacciona al botón seguirá apagado, y tú creerás que el loop no está activo. Eso, en directo, es un error grave.

La regla práctica: el LED debe leer el estado, no recordar la última pulsación.

Cuando el fabricante no documenta los códigos

Aquí es donde mucha gente se atasca. No todos los fabricantes publican la lista de mensajes de salida de su equipo.

Lo que la documentación recomienda en ese caso es interceptar los mensajes:

• El modo de depuración de controladores, que registra todos los mensajes MIDI entrantes y salientes.
• Un monitor MIDI como MIDI-OX en Windows o MIDI Monitor en macOS.

Y el método a seguir es sencillo aunque laborioso: mover el control en el software oficial del fabricante, ver qué mensaje sale, y reproducirlo desde tu mapping.

Ese trabajo de documentación es exactamente lo que después permite crear soporte para un controlador que no lo tenía, y es la puerta de entrada al terreno del reverse engineering que trata este bloque más adelante.

Apagar los LEDs al cerrar

Un detalle pequeño que delata un mapping cuidado: si no apagas los LEDs al cerrar el programa, pueden quedarse encendidos en el equipo.

La solución es la misma que la del encendido, pero en el otro extremo: enviar el estado apagado en la función de cierre del controlador. Es un caso clásico y muy visible, porque el usuario lo ve cada vez que termina de pinchar.

En los programas con scripting, esa función de cierre existe y es donde corresponde hacerlo. En los que tienen columna de salida, basta con asegurarse de que el estado inicial del programa coincide con el del equipo.

Errores frecuentes

• Dar por hecho que el LED viene incluido con la función. No viene incluido: es una asignación de salida.
• Buscar un «Learn» para la salida. En Traktor la asignación de salida es manual por diseño.
• Enviar el LED desde la función del botón, con lo que se desincroniza al usar el ratón o el teclado.
• Repartir números de color por el código en lugar de guardarlos en una tabla con nombre.
• No apagar los LEDs al cerrar y dejarlos encendidos.
• Suponer que el fabricante documenta los códigos de salida. Muchas veces no, y hay que interceptarlos.
• Confundir que un LED no funcione con que el mapping esté mal. Suele faltar solo la mitad de salida.

Siguiente paso

Ya tienes el feedback visual resuelto, que es lo que hace que un mapping se sienta profesional. Queda el elemento del equipo que más problemas da y con más diferencia entre protocolos: los jog wheels. Y ahí ya no se trata de mapear bien o mal, sino de qué protocolo usa tu controladora, que es justo lo siguiente.