Cómo construir un controlador MIDI para Stems o FX

Hay un punto en el que seguir tocando el mapping deja de resolver nada. Ya has usado capas de shift, ya has reasignado los pads y ya sabes que el software acepta los mensajes que le mandas. Aun así te siguen faltando cuatro faders para los stems, un mando de cantidad de FX que puedas coger sin cambiar de capa y una forma de saber qué está activo sin mirar el portátil.

Cuando llegas ahí, la pregunta ya no es qué mensaje MIDI asignar, sino qué hardware te falta. Esta guía es de decisiones: qué controlar, con qué componentes, con qué retroalimentación y con qué requisito de compatibilidad. La soldadura queda fuera a propósito: lo que determina si el aparato acaba siendo útil se decide antes de comprar la primera pieza.

Por qué tiene sentido un controlador propio

Un mapping amplía lo que ya tienes; no inventa mandos. Si tu controladora tiene dos knobs de FX libres y tú necesitas cuatro gestos simultáneos, ninguna asignación te los va a dar. Los tres huecos que más se repiten son estos:

• Stems: hacen falta controles por tallo. Cuatro faders de volumen y cuatro botones de silencio son más gestos de los que una capa de shift puede dar.
• FX: quieres cantidad y activación a la vez, sin cambiar de capa ni de página, y con el estado visible.
• Estado: necesitas comprobar de un vistazo qué está activo, y eso se resuelve con LEDs o con una pantalla.

Además, construir tu propio aparato tiene una ventaja que conviene decir en voz alta: no tocas ningún equipo comercial. No hay firmware de terceros, ni mods, ni garantía en juego, ni riesgo de bloqueo. Los riesgos de un mod no aplican aquí: no estás modificando nada, estás construyendo.

Las decisiones de diseño antes de comprar nada

Antes de añadir nada al carrito, resuelve cuatro preguntas en este orden, porque cada una condiciona la siguiente:

1. Cuántos controles y de qué familia. No es lo mismo un botón que un encoder: cambia el mensaje que envías y cómo se comporta el mando en cabina.
2. Si necesitas LEDs. Añaden cableado, resistencias y firmware, pero también son la diferencia entre saber y suponer.
3. Si necesitas pantalla. Es la decisión más cara en esfuerzo, y por eso va después de las otras dos.
4. Si quieres compatibilidad sin drivers. Esta decide la placa y, con ella, el resto del proyecto. Si eliges mal aquí, toca rehacerlo.

La tabla siguiente resume las cuatro familias de control y para qué sirve cada una.

Botones, knobs, faders y encoders: cómo elegir

Un pulsador es un contacto momentáneo: no tiene memoria de estado, así que es el software quien decide si actúa como interruptor o como disparo. Para silenciar stems y alternar FX es la opción directa.

Un knob (potenciómetro) y un fader son controles absolutos: su posición física es su valor. Eso es cómodo hasta que el valor del software y la posición física no coinciden; ahí entra en juego el soft takeover, y conviene tenerlo previsto al diseñar la disposición. Ambos envían Control Change con un valor de 0 a 127. Si necesitas más resolución que 127 pasos, existen pares de mensajes que dan 14 bits a cambio de duplicar el tráfico.

Un encoder gira sin topes. Tienes que decidir si lo tratas como absoluto (le mapeas un rango completo) o como relativo (envía incrementos y decrementos y el software suma). Para navegar listas o ajustar un parámetro acumulativo, lo que quieres es el relativo.

Dos avisos. Las direcciones de control son un recurso compartido y el estándar reserva los números 120 a 127 para mensajes de modo de canal: no los uses para tus mandos. Y una matriz de botones con pulsaciones simultáneas necesita diodos, o el firmware leerá combinaciones fantasma que tú no has pulsado.

LEDs y pantalla: cuándo aportan algo

Un LED no es decoración. En cabina, la diferencia entre un botón que se ilumina y uno que no es la diferencia entre saber si el stem está silenciado y tener que comprobarlo. Pero cada LED hay que gobernarlo: necesita su resistencia, su sitio en el cableado y su parte de firmware.

Lo importante está en cómo se actualizan. Los LEDs se controlan enviando MIDI de vuelta al controlador, y conviene hacerlo desde funciones que reflejen el estado real del software, no desde el manejador del botón. Si lo enciendes desde el pulsador, el LED miente en cuanto el estado cambia por otra vía: un atajo de teclado, otra controladora o una acción automática.

La pantalla es otra liga. La vía estándar de Control Change no transporta texto, así que una pantalla exige mensajes SysEx o un protocolo propio, y eso significa depender de que cada software lo soporte. Si quieres empezar, hazlo con LEDs; añade pantalla cuando el aparato ya funcione y sepas exactamente qué información te falta. Una alternativa razonable es una pantalla que muestre solo lo que tú mismo envías, sin esperar a que el software te lo cuente.

Compatibilidad sin drivers: la decisión que decide la placa

Un controlador que no necesita drivers se presenta al sistema como un dispositivo MIDI estándar: el sistema operativo ya trae el controlador, así que no hay nada que instalar. Es lo que el sector llama USB MIDI class-compliant, y conviene ponerlo por escrito como requisito antes de elegir nada. Las consecuencias prácticas son tres:

• Funciona igual en Windows, macOS, Linux, Android e iOS, sin instaladores ni permisos de administrador.
• Lo ve cualquier software que acepte entradas MIDI, no solo el que usas hoy.
• No dependes de que alguien mantenga un driver para tu invento.

El contraste es un aparato que exige su propio driver: queda atado a los sistemas que ese driver soporte y al tiempo que su autor quiera mantenerlo. Para un controlador de DJ, que solo envía mensajes cortos, no hay motivo para aceptar esa dependencia. Las plataformas que ya lo cumplen lo declaran en su lista de características: busca ahí antes de comprar.

En la práctica, la decisión se toma al elegir la placa: necesitas una con USB nativo y firmware que se enumere como dispositivo MIDI estándar. Si eliges una que no puede presentarse así, acabarás necesitando un adaptador o un driver propio, y habrás perdido la ventaja principal del proyecto.

La lógica del firmware: leer entradas, enviar MIDI, gestionar LEDs

El firmware que necesitas hace tres cosas, y las tres se ejecutan en bucle, sin bloquearse nunca.

Leer entradas. Botones, knobs, faders y encoders. Un pulsador real genera varios cambios en pocos milisegundos: hay que filtrar el rebote. Un potenciómetro da una lectura con ruido: conviene suavizarla o enviar solo cuando el cambio supera un umbral. Un encoder no da un valor, da dos señales desfasadas que hay que convertir en una dirección. Y cuando hay más controles que pines, entran en juego los multiplexores y las matrices.

Enviar MIDI. Cada control tiene su mensaje: Note On/Off para botones, Control Change para continuos. Decide desde el principio el reparto de canales, porque separar por deck simplifica el mapping, y no inundes el puerto: un fader que envía en cada fluctuación satura el flujo y hace que el resto de controles responda tarde.

Gestionar LEDs. El aparato es bidireccional: además de enviar, recibe. El firmware mantiene el estado de cada LED y lo actualiza cuando llega un mensaje del software. Si enciendes el LED dentro del manejador del botón, ese LED se desincroniza en cuanto el estado cambia por otra vía.

Y una regla que resume las tres: nada de esperas. Si el bucle se para, leyendo un sensor lento o esperando una respuesta, el controlador se siente muerto.

Partir de una plataforma existente en vez de cero

Escribir el firmware desde cero es posible y te da control total. También te da la obligación de mantenerlo: descriptores USB, filtrado de rebote, análisis de MIDI, gestión de LEDs y, cada vez que quieras cambiar algo, recompilar y volver a flashear.

La alternativa es partir de una plataforma que ya resuelve esa capa. En el enfoque de OpenDeck, los componentes se conectan a una placa y el configurador web permite personalizar cada aspecto del controlador: no diseñas el circuito ni programas el firmware. La plataforma está pensada tanto para prototipar como para construir un controlador propio, y su página oficial declara USB MIDI sin necesidad de drivers y soporte universal en Windows, macOS, Linux, Android e iOS.

Cuándo no basta: si necesitas una pantalla con protocolo propio, un formato o una disposición que la plataforma no contempla, o una lógica que el configurador no expresa. En ese caso tienes dos caminos honestos: aceptar el límite o asumir el firmware propio con todo lo que implica.

Antes de comprometerte con cualquier plataforma, comprueba que el proyecto siga mantenido, qué licencia tiene y si la comunidad responde. Y prototipa en una protoboard antes de mecanizar nada: casi todo el coste de un error de diseño se paga en la carcasa.

Siguiente paso

Si la idea de partir de una plataforma hecha te encaja, toca conocerla en detalle: qué problema resuelve, cómo se configura y para qué proyecto encaja. Eso es lo que cubre opendeck-controlador-diy, la guía que cierra este bloque de hardware casero.

Si todavía no tienes claro el reparto de mensajes por control, el punto de partida sigue siendo que-es-midi-mapping-dj; y para la parte de retroalimentación con luz, leds-rgb-mapping-dj.