Jog wheels en MIDI y HID: por qué unos funcionan mejor que otros

Hay un control que da más problemas que ningún otro en el mundo del mapping: el jog wheel. Y no es por falta de habilidad de quien lo mapea. Hay una limitación medible en el protocolo, y hay una segunda razón, menos conocida, que explica muchos casos de «solo me funciona la mitad».

Esta guía cierra el hilo que se abrió al comparar MIDI con HID. Allí quedó dicho que MIDI no puede seguir movimientos rápidos. Aquí está por qué, con el número exacto.

El número que lo explica todo: 128

La documentación de Mixxx, al explicar cómo se configura un jog wheel, indica que hay que darle la resolución del control MIDI en intervalos por vuelta, típicamente 128.

Detente en ese número. 128 es exactamente el rango de un mensaje de control MIDI: valores de 0 a 127.

No es una coincidencia. Es la misma cosa vista desde dos sitios. Un control MIDI corriente entrega 128 posiciones, y la configuración típica de un jog refleja justo eso: 128 intervalos por vuelta completa del plato.

Traducido a la práctica: al girar la rueda una vuelta entera, el software recibe 128 avisos. Para doblar el tempo es suficiente. Para scratch, donde necesitas seguir el movimiento de la mano con detalle, es grueso. Y cuando giras rápido —justo cuando más precisión quieres— esos 128 pasos se agotan antes que tu mano.

Ahí está el «va a saltos» que todo el mundo describe. No es tu equipo ni tu mapping: es la resolución.

MIDI contra HID: dos modelos, no dos calidades

La explicación de fondo la da la documentación de VirtualDJ, y es más elegante que decir «HID es mejor»:

• MIDI es un modelo push: el controlador envía los datos cuando le apetece, aunque la aplicación no esté lista para procesarlos.
• HID es un modelo pull: el software pide los datos cuando puede procesarlos.

De ahí se derivan las dos consecuencias que importan para un jog: mejor latencia y la posibilidad de que existan elementos que se mueven muy rápido sin poner en apuros al sistema.

Por eso la conclusión del fabricante es tan directa: MIDI está muy mal adaptado a controladoras con jog wheels. No es una opinión sobre calidades; es una consecuencia del modelo de comunicación.

Y de ahí también que no puedas arreglarlo con mapping: ninguna asignación crea resolución que el protocolo no tiene.

Los dos gestos de un jog y qué necesita cada uno

Aquí está la segunda razón, la que explica los casos de «solo funciona la mitad», y es un malentendido muy extendido.

Un jog wheel de cabina no hace una cosa: hace dos, y se comportan distinto, como en un tocadiscos.

1. Tocado por arriba → scratch. El plato imaginario sigue a tu mano.
2. Tocado por el lateral → pitch bend. El tempo se acelera o se frena temporalmente y vuelve.

Son comportamientos independientes, y el software no puede adivinar cuál quieres: se los tienes que declarar. Por eso es tan común encontrarse un jog que solo hace una de las dos cosas. No está roto: está a medio mapear.

Y hay una pieza que la gente olvida, porque no es «el giro»: el sensor de toque. El software necesita saber que estás tocando la rueda, y eso llega por un mensaje aparte —normalmente un mensaje de nota— que el sensor envía al presionar. Sin ese mensaje, no hay scratch posible por bien mapeado que esté el giro.

Cómo se implementa un jog por MIDI

Esto es lo que hace de verdad un mapping de jog, con las funciones reales documentadas. Merece la pena verlo porque explica por qué el mapping de un jog es más delicado que el de un botón.

La parte de arriba: scratch

El software mantiene un «disco imaginario» y hay que darle tres cosas cuando empieza el toque:

• La resolución del control: los intervalos por vuelta, típicamente 128.
• La velocidad del disco imaginario a 0 % de pitch, en revoluciones por minuto: típicamente 33 + 1/3, como un vinilo. Se ajusta por comodidad.
• Los coeficientes de un filtro alpha-beta, que juntos afectan a la respuesta y a la «flojedad» del fieltro imaginario. Los valores de partida que documenta Mixxx son alpha = 1/8 y beta = alpha/32, y de ahí se afina.
• Y si quieres que el plato baje de velocidad con rampa o se pare en seco.

Después, cada vez que la rueda se mueve, se registra el desplazamiento: típicamente +1 para un tick hacia delante y −1 hacia atrás. Y al soltar, se le dice que pare, con la opción simétrica: subir con rampa o saltar al instante. La rampa es además lo que permite los spin-backs.

Fíjate en el detalle del filtro: estás simulando un fieltro. No es un parámetro de audio: es lo que hace que la rueda se sienta como un plato y no como un deslizador. Ahí está la diferencia entre un scratch que se siente bien y uno que se siente mecánico.

La parte del lateral: pitch bend

Aquí hay una bifurcación que conviene entender, porque es donde más mappings se equivocan.

Cuando la rueda no está siendo tocada, el mismo giro debe doblar el tempo. La lógica documentada es exactamente esa: si el plato está en modo scratch, el movimiento se registra como scratch; si no, se aplica como pitch bend.

Es decir, el mismo mensaje significa dos cosas según el estado del sensor de toque. Ese es el corazón de un mapping de jog.

El detalle que rompe los jogs: dónde está el centro

Un mensaje relativo no dice una posición: dice un desplazamiento. Pero los equipos no coinciden en cómo lo numeran, y ahí aparecen los jogs que giran al revés o que se van solos.

Los dos casos documentados, y hay que elegir solo uno:

• Rueda que centra en 0: si el valor es menor que 64 se usa tal cual, y a partir de ahí se le resta 128. Así el rango se convierte en una escala centrada en cero.
• Rueda que centra en 0x40 (64): basta con restar 64 al valor recibido.

Si eliges la conversión equivocada, el mando no falla de forma evidente: funciona al revés o arrastra un desplazamiento constante. Es un error difícil de diagnosticar si no sabes que el centro es una decisión de configuración.

Y un aviso más, que ahorra depuración: algunas ruedas envían el mismo mensaje al pulsar y al soltar. Si tu detección de toque se basa solo en el tipo de mensaje, el plato se quedará en modo scratch para siempre. Hay que comprobar también el valor.

Un caso de soft takeover que solo aparece con los jogs

Hay una interacción fina que documenta Mixxx y que conecta con la guía de soft takeover: si cambias de capa y el usuario no ha movido el mando antes del siguiente cambio de capa, el programa puede iniciar soft takeover por error si el usuario mueve el mando lo bastante rápido.

Es un caso que casi nunca aparece con un knob y sí con un jog, precisamente porque el jog se mueve rápido por naturaleza. Sirve para recordar que las capas y el soft takeover no son temas independientes: sus efectos se cruzan.

Por qué en Serato esto no se discute

Un dato que cierra la comparación entre programas: Serato deja los jog wheels y platos directamente fuera del mapping.

Su documentación los incluye en la lista de limitaciones actuales, junto con los interruptores de entrada, los botones Shift y los botones de modo de pad de performance.

Y es una decisión lógica. Si la resolución de MIDI no da para un scratch decente, ¿para qué abrir la puerta a que la gente monte un jog que se sienta mal y parezca culpa del software? Otros programas te dejan intentarlo; Serato directamente te lo ahorra.

La conclusión práctica para ti: si buscas buen scratch, no lo vas a conseguir por mapping. Ni en Serato —donde no se puede— ni en los que sí te dejan, porque el techo lo pone el protocolo.

Qué es razonable esperar

Para cerrar con expectativas honestas:

• Doblar el tempo con la rueda: funciona bien por MIDI. Es un movimiento lento y controlado, y 128 pasos bastan.
• Navegar por la pista o dar nudges: también funciona.
• Scratch preciso: la sensación nunca será la del software oficial del fabricante. No porque ellos tengan un truco, sino porque suelen usar HID o un protocolo propio para esa parte.
• Comprar una controladora esperando que el jog vaya igual en cualquier programa: pide antes el soporte de HID. Es el único dato que importa aquí.

Errores frecuentes

• Culpar al mapping de la falta de resolución. Ningún mapping crea pasos que el protocolo no tiene.
• Implementar solo el scratch o solo el pitch bend. Son dos comportamientos y hay que declarar los dos.
• Olvidar el sensor de toque. Sin el mensaje de toque no hay scratch, por bien mapeado que esté el giro.
• Elegir mal el centro del mando. El jog gira al revés o arrastra un desplazamiento.
• No comprobar el valor en la detección de toque. Algunas ruedas envían el mismo mensaje al pulsar y al soltar.
• Buscar el jog en el mapping de Serato. Está excluido por decisión del fabricante.
• Confundir forzar el modo relativo con ganar precisión. Relativo describe el movimiento; no añade resolución.

Siguiente paso

Ya tienes los dos elementos que dependen del protocolo: el jog, que funciona peor cuanto más rápido giras, y los LEDs, que son asignaciones aparte. Queda el tercero, y es el más dependiente del fabricante de todos: las pantallas que muestran información sobre el propio mando, donde la pregunta ya no es cómo mapear sino quién habla ese dialecto. Es la siguiente.