Sintetizadores

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.

Introducción (¿NRPN sustituto de SysEx?)

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.
 

Los mensajes de controlador

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 http://www.hispasonic.com/tutoriales/sysex-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.

Los límites de los CCs

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.

Cuándo usar CCs

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).

Al rescate: mensajes RPN y NRPN

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.

Ejemplo de contrucción de mensajes NRPN

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.

Diferencia RPN / 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.

Mensaje de ‘fin’ de NRPN o RPN

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.

Para el hispasónico ‘reto’ (NRPNs del EMX-1)

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:

Pablo Fernández-Cid
EL AUTOR

Pablo no puede callar cuando se habla de tecnologías audio/música. Doctor en teleco. Ha creado diversos dispositivos hard y soft y realizado programaciones para músicos y audiovisuales. Toca ocasionalmente en grupo por Madrid (teclados, claro).

¿Te gustó este artículo?
34
Comentarios
  • 1
  • 2
  • #1 por Mister Carrington el 19/04/2013
    Pedazo de artículo. Clarito, clarito.

    El que se queje de "densidad" no tiene razón. ¿Alguien lo mejora?

    :platano:
  • #2 por pablofcid el 19/04/2013
    (Muchas gracias, Mr. Carrington, siempre tiene uno la duda de cómo acometer estas cosas y dónde poner el límite)

    Ya sabéis que si alguien no ve claro algo, tiene abierta la puerta de los comentarios y yo mismo (u otros hispasónicos) trataremos de aclarar lo necesario.
    Los que queremos ir más allá de los 'presets' tenemos que pagar el precio de estos esfuerzos adicionales, pero los resultados lo merecen, así que ¡ánimo y a por los NRPNs!
    1
  • #3 por Juan Ramos el 19/04/2013
    Fántastico Pablo, gracias.
  • avatar
    #4 por --458002-- el 19/04/2013
    Brutal¡ gracias otra vez Pablo. Estoy seguro de que si escribieras un libro sería uno de esos de 'lectura obligatoria'. Ahí lo dejo caer.. ;)

    Comentar que la opción de cambiar de timbre en la emx asignando en el controlador un botón: prog.+ / prog.- es coj... lástima que la esx no lo permita en sus muestras. Porque no lo permite ¿Cierto? ¿Alguien lo ha conseguido?
  • #5 por DeLoreal el 19/04/2013
    Muchas gracias Pablo, pa encuadernar tus artículos!
  • #6 por Poeta el 19/04/2013
    Gracias pablo, me encantan tus articulos, muy buenos...

    Mi aporte;

    Aqui os dejo un monitor midi gratuito para ver los mensajes midi, y saber que esta ocurriendo, tambien hay varias herramientas super utiles para el analisis del midi:

    http://www.midiox.com/

    Con el MIDI-OX 7.0, Podemos ver el trafico de datos en bruto, y analizarlos.

    #4 Si editas algun libro del tema, va para mi biblioteca inmediatamente de cabeza...

    :birras:
  • #7 por Mister Carrington el 19/04/2013
    ¡Me apunto a la compra de ese libro no escrito! :secreto: :grin:
    1
  • #8 por dorremifasol el 19/04/2013
    Excelente artículo!
  • #9 por JLC el 19/04/2013
    muchas gracias
  • #10 por Albert MadStein el 19/04/2013
    Gracias por estos artículos! Creo que voy a por una BCR y a solucionar por fin lo del miniak....
  • #11 por TpuntoGarcía el 19/04/2013
    Tremendo artículo. Gracias.
  • #12 por Rod el 19/04/2013
    muchísimas gracias en la linea de tus anteriores artículos , buenísimo y muy bien explicado :campeon:
  • #13 por parker25 el 19/04/2013
    que interesante!! gracias!! Yo tambien me apunto a ese libro aun no escrito...

    aunque si no te va mucho lo de los libros, algun taller sobre "control" tambien puede ser una alternativa al libro, no?

    Sabes un monton y lo explicas muy bien

    Enhorabuena
  • #14 por teclas123 el 19/04/2013
    Muchas gracias por el artículo. ¿No hay titulación de doctor en MIDI? Por que desde luego tú eres un catedrático! :grin:
  • #15 por sloppy soul el 20/04/2013
    Qué bueno, Pablo! Muchas gracias :plasplas:
  • #16 por reto el 20/04/2013
    Hola a todos.

    De primeras MUCHAS GRACIAS A PABLOFCID por este pedazo de artículo, también por los anteriores, ya que está todo muy bien explicado y con mucha dedicación.
    1
  • #17 por reto el 20/04/2013
    Por otro lado quiero comentar que el artículo de PablofCid me está sirviendo para controlar los parámetros de las 9 partes de batería de la Korg EMX-1 desde el Novatión Remote SL a través de mensajes NRPN.

    Os preguntaréis el por qué de quererlos controlar así, pues bien, el problema es que si quieres automatizar por separado cada una de esas 9 partes de batería de la Electribe EMX-1 es imposible, ya que las 9 partes de batería están agrupadas en el mismo canal 10 midi, por lo tanto no deja automatizarlas por separado desde un controlador, pero llevo unos minutos haciendo pruebas gracias a este maravilloso artículo de PablofCid y ya estpy obteniendo resultados, estoy automatizando desde el Novation Remote SL y grabando esas automatizaciones en Ableton Live, una gozada.

    MUCHÍSIMAS GRACIAS OTRA VEZ PABLOFCID.

    Un saludo.
  • #18 por pablofcid el 20/04/2013
    Hola reto
    Gracias por comentarnos tu experiencia. Por lo que dices en la emx-1 todos llos sonidos drum van por canal 10, así que habría que corregir el ejemplomque yo daba y poner como primer bye B9 (porque 9 es el número que corresponde al canal midi 10), y en vez de midi channnel 2 poner 10 en el remote, claro.

    Un saludo
    1
  • #19 por reto el 20/04/2013
    Ya me había dado cuenta de eso y lo había corregido.

    De rodas maneras muchas gracia sotra vez.
  • #20 por BlahBlah el 20/04/2013
    En realidad yo no lo veo como un "Sysex vs. NRPN".
    De hecho, los NRPN, como CC que son, es la manera "oficial" de controlar un sintetizador en tiempo real.

    El hecho de que haya implementaciones basadas en Sysex para hacer esto mismo no significa que el sysex se diseñara específicamente para ello (más bien estaba pensado para poder hacer data dumping).

    Cualquier sintetizador con una implementación MIDI correcta, debería basar su control en tiempo real en mensajes de tipo CC (RPN y NRPN).
  • #21 por pablofcid el 21/04/2013
    #20
    De hecho no lo titulo así, sino que es sólo el 'reclamo' en la foto.
    Sysex existía en MIDI desde el comienzo, y sin embargo los NRPN fueron añadidos más tarde.
    Por ello, los primeros sintes MIDI (pre-NRPN) usaban SysEx, y de forma muy temprana se vino usando con mensajes no sólo para volcado sino también para la edición de parámetros. Por ejemplo los Roland tipo MKS, Juno106, etc. o toda la serie de Yamaha con FM (DX, TX, y demás), entre otros muchos.

    Sólo más tarde aparecen los NRPN y son desde luego una opción muy recomendada para la edición de parámetros, dejando los SysEx para volcados y demás.

    Pero aún así, en mi perspectiva no todo son ventajas con los NRPN. Principalmente está la complejidad (no siempre bien ocultada por los secuenciadores) de que en realidad una acción NRPN exige varios mensajes MIDI individuales. En SysEx una actuación sobre un parámetro es un único mensaje, y eso me es muy útil para moverlo confacilidad (para cuantizarlo por ejemplo, o para editar el valor incluso manualmente a veces...). Sin embargo con NRPN son varios mensajes.
    La lástima es que la norma sobre NRPNs es (para mi gusto) demasiado 'abierta'. Deberían haber sido más estrictos. Por ejemplo no dice nada sobre si hay que enviar primnero el MSB o el LSB, o si necesariamente hay que enviar ambos (y hay MSB+LSB tanto en el nº de control como en el valor).
    Se admite el envío de sólo MSB en el valor para cuando el control sólo necesita 7 bits, pero eso implica que algunos aparatos no siempre mandan luego un LSB a cero.
    Al final es un mensaje demasiado variable: a veces longitud 4, a veces 3, si se suprimen los mensajes del nº NRPN (porque sea el mismo que ya había antes) puede ser 2 o incluso 1 sólo mensaje de controlador...
    Al final todo un lío.
    Algunos secuanciadores al cuantizar controladores no tienen estos detalles en cuenta correctamente y desordenan las 4 partes del NRPN.
    La representación gráfica (como la que sí hay para los controladores 'normales') en pocas DAWs se realiza, más bien lo que se ve es como lo que presentaba con Cubase AI: cada controlador por separado, lo quehace imposible usar la herramienta 'lápiz',..., etc.

    Para mi gusto (si yo hubiera tenido voz en la MMA) en lugar de intentar estandarizar una solución nueva 'desvirtuando' lo de los controladores, hubiera creado un mensaje universal sysex para espeficar un nº de parámetro con 14 bits seguido de un valor con 14 bits. El resultado hubiera sido que lo que ahora llamamos NRPN hubiera sido un 'universal sysex parameter change' que tendría las ventajas de ambos mundos: mensaje único, estructura definida (y por tanto representable en las DAWs, fácil de programar en controladores, etc.)

    Pero el problema de las estandarizaciones es siempre el mismo. Al final en MMA son varias las empresas fuertes que están liderando el desarrollo de la norma y cada una intenta imponer su forma de entender las cosas o intenta incluso 'jugar a la contra' definiendo cosas que difieran de lo que otro grande usa. Y eso que es de los pocos estándares 'pacíficos' que conozco, donde las cosas se están haciendo razonablemente bien, sin tanto conflicto entre unas fuerzas y otras.

    Vaya, que desde mi punto de vista ciertamente no hay ningún vencedor en esa supesta lucha 'NRPN vs SysEx'. Cada opción tiene sus pros y contras, y la lástima es que se ha perdido una ocasión para definir ese mecanismo tipo NRPN mediante un universal sysex, que hubiera sido (a mi entender) una combinación perfecta, libre de los problemas de NRPN y a la vez libre de la falta de estandarización de los mensajes sysex no universales.

    Vaya, que para hacer algo 'fuera de los mensajes convencionales' ya estaba sysex y no hacía falta enrarecer más la norma con esto de los NRPNs, que por mucho que haya cuajado y ya sea inevitable y cada vez más usado, no deja de tener algunas dificultades que nacen de ese formato tan 'extraño' de usar varios mensajes para codificar una única acción.
    Es de las pocas cosas que en MIDI veo que se han hecho sin poner todas las neuronas y visión de futuro.
  • #22 por Kerman el 21/04/2013
    Impresionante artículo, justo además estaba creando un programa especial usando NRPN y me viene de lujo para entenderlo al dedillo!!
  • #23 por pablofcid el 22/04/2013
    Os comento algunas cosas que pueden tener interés y que me estáis haciendo llegar por preguntas en privado. Respondo aquí y así nos valen para todos.

    1)
    Una cosa que siempre tenéis que comprobar es la cuestión del canal MIDI. Aseguraos de estar usando el correcto. También habría que asegurarse de tener activado MIDI, y no tener filtrados los NRPN, ni los mensajes de controlador, etc. Generalmente no creo que nadie los estéis filtrando (pero por ejemplo Cubasis de iPad no admite la grabación de mensajes de controlador -salvo un par de ellos-). Insisto, no es lo habitual, pero aseguraos.
    Tampoco es habitual que en el sinte tengáis que activar NRPNs (mientras que con sysex sí que hay sintes en los que tienes variables para activar o desactivar su uso).
  • #24 por pablofcid el 22/04/2013
    2) Una opción muy fácil para saber cómo son los mensajes que tenéis que usar es usar un programa monitor MIDI (que os muestre en pantalla todo lo que llegue por MIDI). Si conectáis el sinte y tocáis algún parámetro, es muy posible (en muchos así sucede) que transmita los mensajes que permiten hacer ese toqueteo del parámetro y así los véis y los podéis copiar.
    Si no tenéis un monitor MIDI podéis usar un secuenciador y grabar. Acto seguido veis lo que se ha grabado.
  • #25 por pablofcid el 22/04/2013
    3)
    Me dicen (es extrapolable a otros equipos y secuenciadores, no sólo a esta combinación) que al
    Alguien escribió:
    grabar en Ableton Live las automatizaciones de varios parámetros de una Electribe EMX-1 desde un Novation Remote SL que he configurado con uso de NRPNs me he dado cuenta que siempre graba la automatización del mismo parámetro que es el DATA ENTRY.
    He hecho varias pruebas y yo creo que símplemente es porque Ableton Live no sabe interpretar los NRPN.


    A ese respecto:
    Supongo que te refieres a que los movimientos que haces desde el Novation Remote configurado con NRPNs sobre varios parámetros de la Electribe sí son grabados y reproducidos bien por Ableton, pero que cuando quieres ir a editarlos usando los gráficos, etc. tienes el problema de que no te representa en una única gráfica cada NRPN sino que te muestra (tipo lo que yo enseñaba en el artículo sobre el Cubase AI) separadamente el NRPN MSB, NRPN LSB y Data Entry MSB y Data Entry LSB, de tal forma que no tienes una curva 'única' para cada parámetro de la electribe que quieres tocar. En vez de eso tienes cuatro curvas y para colmo esas cuatro curvas mezclan los datos de todos los parámetros. Con lo cual es un lío que no hay quien edite.

    Ante eso, y si Ableton (no lo uso, así que no lo sé) no es capaz de mostrar cada parámetro NRPN con su propia curva, lo mejor que puedes hacer para la edición es basarte en lista de eventos, que es lo que sugería en el artículo. En la lista sí puedes ver los cuatro mensajes de cada parámetro seguidos y tratarlos (tú) 'como uno' a la hora de moverlos o de lo que haga falta. No es lo más práctico, pero es de lo mejor que puedes hacer.

    Puedes en esas situaciones usar los 'filtros' a la hora de editar (en Cubase los hay muy completos, con todo el tema del 'logical edit' que te permite poner reglas). Quizá haya algo parecido en tu entorno.

    Otra cosa que se me ocurre es esta: es una posibilidad trabajosa, pero quizá te funcione. Se trataría de que grabes los controles de cada parámetro en una pista (o bien los grabas todos y luego con funciones de tipo 'logical edit' las separas en distintas pistas). Así al menos no se te mezcla todo y puedes intentar editar cada parámetro por separado. Pero siempre sabiendo que luego tienen que combinarse en un único canal MIDI.
    Me refiero a que al separarlos en cada pista te resultadría más fácil corregir valores (podrías usar la herramienta 'lápiz' sobre la curva de data entry), pero sin embargo no deberías jamás modificar la posición (ni cuantizar, etc.) porque si mueves los controles en el tiempo cuando vuelvas a mezclar todas esas pistas no está asegurado que mantengan el orden conveniente para que sigan juntas las cuatro piezas que representan cada acción NRPN.

    Espero que se entienda. Y si alguien tiene una idea mejor que la comparta y así aprendemos todos.
  • 1
  • 2