Control mediante NRPNs en MIDI

Bajo el inocente aspecto de mensajes de controlador (CC) los mensajes MIDI NRPN se usan (cada vez más) en muchos equipos para control en tiempo real (en vez de los complejos SysEx). Estudiamos esta alternativa y cómo aprovecharla.

Sobre el interés de contar con el control de parámetros de los sintes y efectos en tiempo real, ya debatimos ampliamente en la serie presentada recientemente en Hispasonic dedicada al MIDI SysEx. En ella veis diferentes aplicaciones y casos prácticos que podemos resumir en la filosofía ‘un parámetro, un control’: poder gobernar cualquier parámetro interno que deseemos controlar (por ejemplo de los que definen el sonido de un sinte o un efecto), mediante mensajes generados desde un teclado controlador, desde una superficie de control o desde un software de control MIDI.

¿Qué opciones (qué mensajes) nos ofrece MIDI para controlar parámetros? Esencialmente CCs (los tradicionales mensajes de controlador), RPNs y NRPNs, y por supuesto los ya citados SysEx. Cada fabricante decide cuáles y cómo los usa en cada equipo.

Sobre mensajes de controlador (o CCs) hago una mención enseguida, pero en resumen su alcance es insuficiente para un control detallado y completo.

Sobre los mensajes SysEx y su aplicación al control en tiempo real de sintes y equipos en general, os remito a la serie ya publicada. Extraordinariamente capaces, pero complejos (hay que tener una cierta mentalidad técnica para moverse con comodidad con ellos).

Veremos hoy cómo ese mismo grado de control puede en algunos equipos obtenerse no con mensajes SysEx sino con mensajes NRPN (más sencillos). Incluso puede hablarse de cierta ‘moda’: parece últimamente crecer el número de equipos que usan mensajes NRPN, especialmente en aparatos enfocados a música electrónica y ambiente DJ, así como en sintes de ‘escasa’ (a veces no tanto) complejidad, como puedan ser sintes monofónicos o con relativamente pocos parámetros.

RPN y NRPN son las siglas de ‘Registered Parameter Number’ y ‘Non-Registered Parameter Number’. Se trata de permitir tener listas de parámetros asociando a cada uno de esos parámetros un nº (RPN o NRPN) que se usará para poder modificarlo vía MIDI. Los números RPN se definen por la MIDI Manufacturers Association (MMA) y tienen carácter universal: todos los equipos usarán el mismo número para controlar un mismo ‘concepto’ o ‘parámetro’. Los NRPNs son una puerta abierta a que cada fabricante defina su propia lista de parámetros (y son los más usados, porque sólo así puede brindarse acceso a todas las especificidades de un determinado equipo).

Para el mero control en tiempo real de parámetros los RPNs/NRPNs son mensajes que permiten una especificación y gestión sencilla. Los volcados masivos son territorio reservado a los SysEx (los clásicos ‘dump’ para volcar un sonido, volcar todos los sonidos, salvar toda la memoria de la máquina, etc. nunca podrían realizarse con RPN/NRPN). Esa combinación SysEx para volcados masivos y NRPNs para retoque de parámetros individuales aparece en muchos equipos, y es muy buena opción para el usuario final.

Por ejemplo el EMX-1 de Korg: el control en tiempo real se realiza por NRPNs y los volcados por SysEx.
Otro ejemplo más reciente: el control en tiempo real del Elektron Analog Four se realiza con NRPNs (hay también la posibilidad de usar CCs pero eso sólo deja accesibles una parte de los parámetros) y los volcados se resuelven con SysEx.

De las tres alternativas (CCs, NRPNs, SysEx) los CCs son los más sencillos y los menos potentes. Los CCs son mensajes que estaban ya definidos en la norma MIDI inicial.

Vamos a detallar su estructura, la necesitaremos para entender la construcción de RPNs y NRPNs. Constan de tres bytes: Bn cc vv (escribo en hexadecimal, si no sabéis lo que es leed la parte en la que lo menciono dentro de https://www.hispasonic.com/tutoriales/sysex-i-midi-mas-sexsy/37924).

El primero (Bn) establece que se trata de un mensaje de controlador y define sobre qué canal de los 16 existentes opera (mediante ese ‘n’ que admite valores 0, 1, 2… y C, D, E, F para representar canales MIDI 1 a 16).
El segundo (cc) es el ‘número’ de controlador (define el tipo o destino del controlador, entre 0 y 127, o lo que es lo mismo 00 a 7F en hexadecimal).
El tercero (vv) es su valor (posición del control, nuevamente 0 a 127, o si lo preferís 00 a 7F).

Por ejemplo B0 07 7F se ‘lee’ así

B0: inicio de mensaje de controlador en el canal de número ‘0’ (que es el canal MIDI 1)
07: el nº de controlador es el 7 (volumen)
7F: corresponde al valor decimal 127 (es decir, lleva el volumen al máximo)

Los tipos/destinos de controlador son variados. Muchos de esos números tienen hoy definido un significado (todos sabemos que el controlador 7 es el de volumen, o el 10 el de panorámica). Algunos representan la actuación sobre determinados tipos de control físico (1 - rueda de modulación, 2 - breath control,…), otros representan determinados destinos o actuaciones (como mover la frecuencia de corte de un filtro, regular el volumen, modificar la panorámica, controlar el tiempo de la cola de una reverb, etc.).

Debéis consultar en el manual de cada equipo cuáles de estos controladores acepta y cómo reacciona a ellos. En la ‘Table 3’ de este enlace veréis los usos recomendados http://www.midi.org/techspecs/midimessages.php#3. Ni siquiera esa tabla (oficial de la MIDI Manufacturers Association) es necesariamente aplicable en todos los casos, es sólo una recomendación. Lo que manda es una relación parecida que encontraréis en el manual de vuestro equipo particular.

Un problema con los CCs es que su número es limitado. En MIDI sólo puede haber 128 controladores (de hecho menos, porque hay algunos -los números más altos- reservados para funciones muy particulares que no son propiamente de control). Cualquier sinte de hoy usa en un solo programa mucho más allá de 128 parámetros, lo cual impide una edición completa usando CCs en la mayoría de los casos. Otro problema es que el rango de valores para los parámetros es también limitado (se mueve entre 0 y 127: no es muy grave para un volumen, pero intentar un barrido de un filtro con sólo 127 escalones puede hacer que se noten los saltos individuales).

Para esquivar este último problema se han definido parejas de CCs (esencialmente cada uno de los CCs con número 0-31 y su correspondiente 32-63): el primero de ellos establece el valor ‘grueso’ y el segundo el valor ‘fino’ (para recorrer el espacio entre dos valores ‘gruesos’ consecutivos). En los manuales veréis esto referido como MSB y LSB (la parte ‘más significativa’ y la ‘menos significativa’ de un valor). Reunidos los 7 bits útiles del byte de valor MSB (‘grueso’) y los siete del LSB (‘fino’) obtenemos una precisión de 14 bits disponible para definir el valor de un control (ya sí suficiente para esos barridos de los que hablábamos). Pero incluso con ello, lo único que hacemos es agravar el otro problema: ya ni siquiera tenemos 128 CCs disponibles, pues al emparejarlos disminuimos el número de destinos controlables.

Entonces nos olvidamos del todo de los CCs, ¿verdad? No: si el tipo de control que necesitáis está disponible en forma de CC, no os compliquéis la vida. Con controles relativos a volumen, generalmente los sintetizadores sólo responderán al controlador MSB (en el caso del volumen el 7) pero no reaccionarán (o no con significado de volumen) al control 39 (que sería el correspondiente al supuesto LSB para el volumen). Sin embargo en muchos sintes sí veréis que el control mediante CCs de la frecuencia de corte sí reacciona tanto a MSB como a LSB. Así que, verificando que los parámetros que queréis tocar están disponibles mediante CCs y con una precisión adecuada (con el tema MSB+LSB en el caso de los más ‘sensibles’) no hay razón para no usarlos. Al contrario, cabría recomendarlos.

Es un mensaje breve (muy compacto y rápido cara a su transmisión vía MIDI), que cualquier controlador sabrá normalmente generar y que se gestiona sin problemas (cualquier secuenciador tendrá opciones para edición de su valor, para representarlo gráficamente, etc.). Los faders y pots de los teclados y superficies de control pueden normalmente especificar el uso de CCs de 14 bits (enviarán los dos mensajes correspondientes al MSB y al LSB consecutivamente).
En definitiva, si con CCs podéis cubrir vuestras necesidades no hay porqué intentar otras cosas más complejas, porque perderéis las facilidades que existen para los CC. Por ejemplo, en la figura veis la representación en Cubase de los datos de un CC (en este caso el control nº 10 que es el de panorámica para un canal MIDI –podría incluso ‘pintar’ el movimiento deseado-).

Desde luego no contaremos con ese tipo de representación gráfica para los SysEx (porque al ser exclusivos, cada uno tiene una estructura diferente y los fabricantes no pueden preveerla) y tendremos que bastarnos con la edición ‘de lista de eventos’. En el caso de los NRPN y RPN, dado que su estructura sí es conocida, puede haber sistemas que realicen su presentación gráfica (aunque no es lo habitual, como veremos más adelante).

Como forma de superar los problemas de los CCs que hemos indicado (su escasez en número y su poca resolución) se idearon los RPNs y NRPNs (Registered Parameter Numbers y Non-Registered Parameter Numbers). No formaban parte de la primera especificación de la norma MIDI (surgieron unos años después) pero han tenido bastante éxito y son muchos los equipos que los usan.

Podemos considerarlos un mecanismo para extender los CCs más allá de los límites de los 128 controles y de los valores de 7 bits (0-127). Se han reservado unos números de controlador para poder con ellos especificar un nº de parámetro. El número se especifica usando un par de controles (MSB+LSB), de forma que tenemos 14 bits y por ello más de 16000 ‘destinos’ de control posibles (difícilmente querremos más en un único equipo). En cuanto al ajuste del valor al que queremos situar el control, se usan otros dos mensajes de controlador: el control ‘Data Entry’ (de nuevo en forma de un par MSB+LSB, y por tanto con una precisión amplia de 14 bits).

Si vais a la lista del significado recomendado por la MMA para los controladores MIDI, veréis (extracto) lo siguiente:

0 Bank Select MSB (el 32 sería el LSB)
1 Modulation Wheel MSB (el 33 sería el LSB)
2 Breath Controller MSB (el 34 sería el LSB)
3 Undefined MSB (el 35 sería el LSB)
4 Foot Controller MSB (el 36 sería el LSB)
5 Portamento Time MSB (el 37 sería el LSB)
6 Data Entry MSB (el 38 sería el LSB)
(…)
96 Data Increment (Data Entry +1)
97 Data Decrement (Data Entry -1)
98 Non-Registered Parameter Number (NRPN) - LSB
99 Non-Registered Parameter Number (NRPN) - MSB
100 Registered Parameter Number (RPN) - LSB*
101 Registered Parameter Number (RPN) - MSB*
(…)

Para completar una orden NRPN (o RPN) primero enviamos el número del parámetro (dos mensajes de controlador, que serán los nº 99 y 98 para NRPN, o 101 y 100 para RPN) y a continuación enviamos la posición o valor deseado para ese parámetro con Data Entry (de nuevo dos controladores, 6 y 38) o bien con Data Inc / Data Dec (96 o 97) si se trata sólo de incrementar o decrementar el valor que ya tenía.

Ya estamos en condiciones de hacer algún ejemplo, que centraremos en NRPN (luego comentaremos los RPNs, pero sabed ya que la estructura es idéntica).

Voy a usar como ejemplo el Analog Four de Elektron (del que recientemente hice una ‘review’ para hispasonic), principalmente porque es de los pocos que admite control tanto por CCs como por NRPNs, y eso nos permitirá apreciar muy bien las diferencias:

Voy a centrarme en la parte relativa al filtro. Os resumo recopilada la información que nos interesa del manual. Muestro la parte relativa al filtro 1 (la sección ‘filtros’ del Analog Four incorpora dos por cada voz):

Por tanto sería factible modificar vía MIDI sobre la marcha (entre otros) la frecuencia de corte y la resonancia (y así hasta completar un total de más de medio centenar de parámetros en cada voz).

Enseguida nos centramos en NRPN, pero vamos a comparar el control con NRPN y con CC: podéis ver que de esos 5 parámetros sólo 3 pueden tocarse con CCs. Sería imposible ajustar el ‘overdrive’ y el ‘keytracking’. Recordad que el número de CCs es muy limitado, y no da para cubrir todos los parámetros de un sonido del Analog Four. Fijaos también cómo, pese al uso de CCs, es factible controlar la frecuencia de corte mediante CCs con resolución de 14 bits: se usan los controles 18 y 50 (lo que os comentaba antes sobre ‘emparejamiento’ de CCs en la norma MIDI). El problema principal es por tanto que nunca los CCs van a ser suficientes para poder controlar todos los parámetros de un sinte medianamente complejo. Así que vamos con los NRPNs.

Para controlar la frecuencia de corte usaríamos el NRPN con MSB 1 y LSB 40 (o 01h y 28h en hexadecimal). Y el valor podemos especificarlo con el Data Entry, ya sea en sólo 7 bits (usando sólo el controlador 6) o como sería más razonable usando el Data Entry de 14 bits (que usaría el controlador 6 como MSB y el controlador 38 como LSB -en hexadecimal sería 06h y 26h-).
Para controlar la resonancia (un parámetro en el que no es necesaria la precisión ampliada a 14 bits) el Analog Four sólo atenderá a la parte MSB del Data entry (el controlador 6) así que no se necesita enviar la parte LSB.

Los mensajes oportunos los podréis ‘programar’ en vuestro secuenciador o los podréis generar ‘en vivo’ con un controlador que genere NRPNs.

Aquí tenéis los ajustes necesarios para que 4 faders de un Roland A800Pro gobiernen esos dos parámetros (voy a suponer que el canal MIDI en el que queremos actuar es el 1).

¿Sencillo verdad? Al menos comparado con el esfuerzo que suponía el control mediante SysEx, esto es claramente más accesible por cualquiera. Basta localizar el número de NRPN (compuesto de sus dos partes MSB y LSB) y especificarlo en nuestro controlador.
Concrétamente en el caso del Roland A800 Pro que estoy usando en esa figura, veis que sólo permite especificar el rango de valores que podrá adoptar ese parámetro mediante 7 bits (de 0 a 127, lógicamente aplicados a la parte MSB del valor). En otros controladores sí se permite el uso de 14 bits para el valor (que sería recomendable para evitar el efectos ‘escalera’ al mover la frecuencia de corte).

Para que lo podáis ver ‘al completo’ (con los 14 bits en el valor), he usado una app de control MIDI para iPad (TB MIDI Stuff) y programado un control NRPN (de forma parecida a lo realizado con el A800Pro pero especificando el uso de 14 bits para la posición del control). Y aquí tenéis el volcado (capturado con un monitor MIDI) de lo que se produce al mover el control (sería el mismo tipo de lista que veríais con el clásico editor de lista de eventos en un secuenciador MIDI). Veis con claridad como cada ajuste de un control mediante NRPN implica en realidad cuatro mensajes MIDI consecutivos de controlador.

Para poder ajustar el valor de un parámetro que esté alcanzable mediante NPRN o RPN, deben aparecer por tanto los siguientes mensajes:

1. Sendos mensajes de los CCs 99 y 98 (o 101 y 100) para especificar el MSB y LSB del número de parámetro NRPN (o RPN)
2. Tras ellos la especificación del valor que debe adquirir ese parámetro, mediante Data Entry (que usa los controles 6 y 38 para el MSB y LSB)

Esos mismos 4 mensajes encerrados en la caja roja, vistos en ‘bruto’ y en hexadecimal, serían así:

B0 63 01 B0 62 40 B0 06 00 B0 26 62

Si seguimos moviendo ese mismo control, bastaría en principio enviar los mensajes Data Entry (porque el número de parámetro no cambia, haciendo innecesario volver a transmitir los CC 99 y 98 o 101 y 100). Aunque tal como veis en la imagen con la captura real, muchos controladores usan siempre los cuatro mensajes individuales.
Si basta para el parámetro usar sólo siete bits enviaremos el MSB de Data Entry (sin enviar el LSB, o bien enviándolo a cero). Y si se trata de un mero incremento o decremento de valor podemos usar los mensajes Data Inc / Data Dec (controles 96 y 97 respectivamente), aunque hay muchos controladores y equipos que obligan al uso de Data Entry (no generan / reciben los Data Inc / Data Dec).

¿Para qué os cuento todo este análisis de los mensajes que intervienen? Desde luego si os limitáis a configurar vuestro controlador y tocar/grabar con él, no hace falta bajar a estas tripas. Pero si, como yo, luego os gusta hacer edición detallada, entonces sí necesitaréis saber interpretar los mensajes con ese detalle.

Este detalle os permitirá ‘entender’ (leer) esas ristras de mensajes MIDI. Pero sobre todo debe haceros conscientes de cómo (si lo llegáis a necesitar) debéis tratar esos mensajes. Por ejemplo, no podéis borrar un ‘Data Entry’ y pretender que el ‘Data Inc/Dec’ que venga más tarde actúe como debe.
Más claro: aunque hablamos de mensajes NRPN / RPN, en realidad se trata un grupo de mensajes de CC que deben entenderse y tratarse como un todo.
Por ejemplo, si queréis cuantizar los mensajes de control (eso a mí me gusta, para tener modificaciones ‘a tempo’ como si se tratara del clásico efecto ‘Sample and Hold’) tenéis que atender a todas esas ‘partes’ de la acción NRPN, y debéis asegurar que siguen en el orden correcto (si al cuantizar el Data Entry se adelenta al número NRPN, desastre asegurado).

Normalmente usaremos editores tipo 'lista de eventos' para poderlos seleccionar y tratar juntos.

Algunos secuenciadores son capaces de mostrar y editar gráficamente el control ejercido mediante NRPNs (de la misma forma en la que mostramos anteriormente el CC de panorámica en Cubase). Pero fijaos qué pasa cuando un programa no sabe ‘tratar en grupo’ los cuatro mensajes que forman cada nuevo valor para un parámetro mediante NRPN (estoy mostrándoos lo que presenta la pantalla de una DAW muy básica -Cubasis AI- que se regala con algunos equipos y que carece de los detalles de una versión avanzada):

Es evidente que sin el apoyo de una adecuada representación gráfica (que en este ejemplo no existe) deberemos limitarnos a trabajar sobre la lista de eventos, para poder tratar conjuntamente los cuatro mensajes individuales que forman el retoque de un valor NRPN.

Si recordáis lo que comentamos en la sobre serie SysEx en relación con los ‘Universal SysEx’, se trata de algo parecido.
La idea de tener una extensión ‘universal’ (los ‘Universal SysEx’ o los ‘RPNs’) es buena, pero en la práctica son pocos los fabricantes dispuestos a someterse a tanta estandarización, por lo que son muy pocos los parámetros que a día de hoy están disponibles para ser ajustados mediante ‘Universal SysEx’ o ‘RPNs’.
En realidad, los pocos RPNs que están estandarizados son algunos que se usan en General MIDI. Los podréis consultar en el manual de vuestro equipo (si es que los utiliza). La estructura y tratamiento de los mensajes es idéntica a lo ya contado para NRPN.

Básicamente, y centrándome en los más comúnmente implementados, General MIDI 1 exige que se atiendan estos RPNs:
00 00 – Rango de PitchBend
00 01 – Afinación ‘fina’ (cents)
00 02 – Afinación ‘gruesa’ (semitonos)

General MIDI 2 añadió este otro RPN: 00 05 – Rango de la rueda de modulación

Si os preguntáis para qué se usan los 00 03 y 00 04, casi nadie los implementa (entenderéis enseguida porqué). Se usan si un equipo puede guardar un gran número de definiciones de afinación de la escala (para salir de la habitual temperada). Esos RPNs son la forma recomendada para escoger qué escala y banco de escalas (al estilo de los programas y bancos de programas) es el que define la escala que debe seleccionarse. Como veis algo bastante enrevesado.

Una última advertencia en relación con NRPNs ( RPNs). La norma establece que hay mensajes para ‘cierre’ o ‘desactivación’ de NRPN (RPN). Es opcional su uso, pero se recomienda encarecidamente. Cuando acabemos de hacer uso de los NRPNs (RPNs), deberíamos preocuparnos de enviar un mensaje de cierre, que no es más que enviar el número de NRPN (RPN) 7F 7F.
Eso indica al equipo que recibe que ya no se va a usar más el ‘Data Entry’ (ni ‘Data Inc’ / ‘Data Dec’) para modificar el valor del parámetro. De esa forma se evitará que si por cualquier causa llega alguno de estos mensajes modifique sin desearlo el último parámetro que se hubiera especificado.
Es por tanto una especie de forma de ‘desconectar’ el mecanismo NRPN / RPN.

O sea, en rigor, una actuación NRPN completa sería

B0 63 01 B0 62 40 B0 06 00 B0 26 62 B0 63 7F B0 62 7F

Pero en la práctica, por lo que yo he visto, muy pocos sistemas realmente hacen uso del ‘cierre’ de NRPN/RPN.

¿Porqué entonces lo del ‘cierre’? Sucede que el ‘Data Entry’ no se inventó específicamente para NRPNs y RPNs. Como sabréis, muchos sintes y equipos cuentan con un control precisamente llamado ‘Data Entry’ (suele ser un fader en el panel frontal) que se usa para modificar el valor de cualquier cosa que aparezca seleccionada en la pantalla del equipo. ¿A que adivináis qué número de controlador usa? Sí, el 6.

Lo que sí permanece (y debe ser la conclusión de este apartado) es la advertencia: cuidado con enviar mensajes de ‘Data Entry’ descontrolados. En especial cuidado si usáis controles NRPN y alguno de vuestros teclados tiene el ‘slider’ Data Entry: más valdrá no tocarlo.

El hispasónico ‘reto’ es el primero que me preguntó por los NRPNs y quería controlar el EMX-1 de Korg. Así que para que tengáis otro ejemplo y él vea atendida su necesidad, aquí tenéis un trozo del manual de implementación MIDI del EMX-1 (podéis descargarlo íntegro en http://www.korg.co.uk/downloads/EMX1/support/EMX1_MIDI_imp.zip):

Vemos que en el EMX-1 se usa sólo ‘Data Entry’ (no se admite Data Inc / Data Dec). Y vemos también que para ver el detalle de los números NRPN hay que acudir a la tabla 1, de la cual os ofrezco el principio:

Por tanto sería factible modificar vía MIDI sobre la marcha (entre otros) la afinación, nivel, pan, etc. de la pista Drum1 (e igualmente Drum2, etc. si siguiéramos leyendo la tabla).
Los mensajes oportunos los podréis ‘programar’ en vuestro secuenciador o los podréis generar ‘en vivo’ con un controlador que genere NRPNs.
Serían mensajes como estos (suponiendo que el canal en el que está Drum 1 sea el canal MIDI 2 porque el canal MIDI 1 esté ocupado por la pista synth –recordad que el canal MIDI 2 aparece en el byte Bn como B1 porque el valor 0 corresponde a canal 1, el valor 1 a canal 2, etc.):

Aquí tenéis los ajustes necesarios para que 3 faders de un Novation Remote SL gobiernen esos parámetros: