Más allá de los 7 bits...

Las capacidades del Environment y sobretodo su concepción no dejan de sorprenderme. Me resulta increíble descubrir nuevas posibilidades y combinaciones de funciones. Y el último descubrimiento es sencillamente magistral: se pueden manejar valores mayores de 127 desde los objetos del Environment. Que Santa Inspiración Divina proteja a Gerhard Lengeling por tener esa increíble visión hace ya muchos años: ¡qué maravilla de programa!

Veamos el porqué de mi efusiva alegría (ojo, esto presupone ciertos conocimientos del protocolo MIDI). Cualquier evento MIDI de canal tiene un límite de valores que va de 0 a 127 (el 0 cuenta como valor), es decir, podemos cambiar valores en un rango de 128 valores distintos. Cuando subimos el volumen con un fader en el Environment se está enviando un evento de control MIDI de 3 bytes: el primero es el de estado (tipo de evento y canal MIDI por el que se transmite), el segundo indica el controlador MIDI que estamos enviando (en el ejemplo volumen, control número 7) y el tercer byte la cantidad que estamos enviando (por ejemplo subirlo hasta el máximo, 127). En el caso de un evento de nota, el primer byte sigue siendo el tipo de evento y el canal MIDI por el que se transmite, pero el segundo byte es el número de nota (de 0 a 127, esto es C-2 a G8) mientras que el tercer byte indica la fuerza con la que se ha pulsado dicha nota (de 0 a 127). Y seguimos… hay 128 cambios de programa en el protocolo MIDI (de 0 a 127), y la post-pulsación (aftertouch) envía valores de 0 a 127 al actuar (tanto el aftertouch de canal como el polifónico que es individual para cada tecla pulsada). ¡Estamos presos en el mundo de los 8 bits!, y además resulta que no se emplean realmente 8 bits, sino 7, por ello existe la limitación de 128 valores. Si se empleasen los 8 bits podríamos manejar 256 valores para cada evento.

El fader de la derecha envía hasta 16383 valores frente a los 127 valores estándar de un controlador MIDI. Observa el campo "Rango" cuyos límites son "0" y "127" (7 bits).

Pero…. Hay un evento de canal que envía valores de 14 bits (ojo que si dividimos 14 por 2 nos da 7, una cifra mágica que ha aparecido al final del párrafo anterior). La rueda de inflexión de tono o pitchbend es un control físico que incluyen los teclados MIDI que al moverse envía un evento MIDI de 3 bytes (como los controladores, notas y aftertouch polifónico). El primer byte es como siempre el tipo de evento y canal MIDI, pero el segundo y el tercero combinan sus valores dando lugar a un límite de 16384 valores (128 x 128). Así el segundo byte se llama LSB y el tercero MSB. Cuando el LSB alcanza su valor máximo de 127, el MSB suma una unidad y espera a que el valor LSB alcance de nuevo el máximo de 127 para subir otra unidad. Y así, combinando esos dos valores se logra dar una resolución de 14 bits que es necesaria para la rueda de modulación, de otra forma los saltos al mover la rueda serían perfectamente audibles (sólo contaría con 128 pasos frente a los más de 16000 que permite)

En este caso el campo "Rango" está definido como "0" y "16383" (14 bits). Además el campo "Filtrar" está configurado como "14 bits" algo IMPRESCINDIBLE.

Y otro “pero” todavía mejor… En el protocolo MIDI es posible usar dos eventos de control combinándolos a modo de MSB y LSB. Esto suele hacerse para “crear” un evento de cambio de banco de sonidos y lo emplean sintetizadores que tienen más de 128 memorias de sonidos. Si estos eventos son enviados en la misma posición de reloj junto con un cambio de programa, el sintetizador pertinente sabe qué banco de sonidos debe seleccionar y qué sonido en particular de ese banco se desea usar.

Valor mínimo a 14 bits: "0", enviado como LSB 0 (control 64) y MSB 0 (control 32)

Valor mínimo a 14 bits: "16383", enviado como LSB 127 y MSB 127.

Secuencia de cambio de valores: se han enviado los valores 124, 125, 126, 127, 128, 129 y 130. Observa cómo el MSB (control 32) del valor 128 cambia de "0" a "1" cuando su LSB (control 64) pasa de "127" a "0".

¿Qué tiene que ver todo esto con REQUIEM?

En el último post hablé de un posible sistema de automatización para REQUIEM. El sistema que estoy barajando implicaría poder grabar hasta 500 compases de automatización con una resolución de 1/32 eventos para cada compás. Y el problema surge en esto: si REQUIEM ofrece hasta 500 compases de automatización, ¿cómo voy a grabar y editarlos si los objetos del Environment sólo pueden emplear y visualizar de 0 a 127 valores? Basta comprobarlo creando un fader en el Environment. El campo “Rango” presenta un límite de 127 como valor máximo. Así pues el contador de compases del Modo Song (Canción) de REQUIEM sólo visualizará hasta el compás 127 (o 128 si usamos el valor 0 como valor funcional).

La forma “barata” de superar esa limitación es trabajar con bancos, por ejemplo tener 10 bancos de 128 compases cada uno. El usuario vería un nuevo dígito a la izquierda del número de compás, y el compás actual como un valor de 0 a 128. Sinceramente no me parece un modo “profesional” de presentar la información, por no decir que manejar y editar los compases puede ser muy arduo al tener que seleccionar siempre el banco de 128 compases en el que estamos operando.

Pero el problema es que el Environment sólo permite ver esos valores “de alta resolución”, pero no manejarlos. Un objeto Transformador sólo procesa valores de entre 0 y 127, y los meta-eventos del Environment sólo saben mover / procesar / disparar valores de entre 0 y 127. Así que… ¿para qué mostrar valores mayores de 127 si no podemos procesarlos?

Respuesta corta: MSB y LSB
Respuesta larga: Dividir ese valor de 14 bits en dos de 7 bits. ¿Hay algo en el Environment que pueda lograrlo?. Por supuesto, un fader definido para enviar valores de 14 bits.

Trataré de abordarlo en el próximo post…

Automatízame un poco, por favor…

 

Hacía unos cuantos días que no me pasaba por este barrio. Confieso que a veces me cuesta “environear”, normalmente después de preguntarme para qué servirá semejante esfuerzo. Aún así, todavía no me he caído: sigo teniendo la esperanza de aunar todas las ideas acerca de REQUIEM y lograr terminarlo.

Hoy toca hablar de las automatizaciones, esto es, poder grabar y reproducir cambios en los controles del interface de usuario. Logic tiene un excelente sistema de automatizaciones, al igual que Cubase, Reason (en menor medida) y la mayoría de secuenciadores de audio y/o MIDI. ¿Y REQUIEM? (dejando a un lado sus potentes 6 LFOs)

Primero veamos en qué consiste un sistema de automatización: se trata de pistas especiales en las que podemos grabar cambios en los controles. Esos datos pueden grabarse de diversos modos: al tocar el fader deseado y moverlo, reemplazando datos existentes, incrementando o reduciendo la automatización existente, etc… La edición suele ser gráfica en forma de curvas o bien en forma de lista (como una lista de eventos). Técnicamente hablando es algo tan sencillo como ir grabando a cierta resolución los cambios en los controles.

¿Cómo se implementa todo esto en un environment para Logic? Lo primero a resolver es cómo grabar esos datos y a qué resolución hacerlo. Es decir, en un compás, ¿cuántos eventos de automatización podremos grabar?, ¿y durante cuantos compases? No valen las respuestas como “a la máxima resolución” y “durante infinitos compases”. REQUIEM es un environment y cuenta con serias limitaciones… 8000 objetos (en la versión 5.5 de Logic, desconozco cual es ese limite en la versión actual) y un ancho de banda de proceso muy reducido (no pretendas procesar 200 streams de datos a través de 200 objetos de forma simultánea…)

Usando el elemento clave en cuanto a construcción de memorias en E-Code, el objeto Transformador, podemos memorizar 128 eventos de automatización. Eso nos podría valer para una resolución de 1/128, es decir, 128 eventos en cada compás. Pero si quiero poder grabar durante 100 compases, deberé usar 100 Transformadores. ¡Y esto sólo para un control en pantalla, imagina si deseamos automatizar 10 controles!

Lógicamente este método no nos vale, hay que reducir la resolución interna. Usando una resolución de 1/32, es decir, 32 eventos de automatización por compás, podemos usar un Transformador para memorizar 4 compases (4 x 32 = 128). Y encadenando más Transformadores, podemos cubrir fácilmente 500 compases. En este caso necesitaríamos 125 objetos Transformadores. Esos Transformadores deberían ir conmutándose entre sí, por ejemplo, al llegar al compás 5 sería el segundo Transformador el que actuaría, al llegar al compás 9, sería el tercero y así sucesivamente. Y lo mejor… se podrían empaquetar esos 125 Transformadores en un par de objetos Macro, convirtiéndolos en ¡2 únicos objetos!

¿Qué podríamos automatizar en REQUIEM?

La idea es poder grabar y reproducir cualquier control de síntesis o control de estado (eso es sencillo), pero lo difícil es hacerlo con todos simultáneamente: harían falta cientos de Macros como la anteriormente citada. Creo que lo mejor es ofrecer varias pistas de automatización, y que sea el usuario el que indique qué control grabará en cada una de ellas. Inicialmente la idea es probar con 4 pistas de 500 compases cada una, con una resolución de 1/32. Esto puede verse limitado por “todas las otras tareas de REQUIEM”, es decir, las 9 pistas de ritmos, las 8 pistas solistas, los LFOs y el manejo del interface de usuario… es decir, ¡el famoso ancho de banda!

Si el rendimiento fuera óptimo, probaría con 8 pistas de automatización (duplicando lo anterior). Con 8 pistas ya es posible efectuar buenas mezclas y efectos de producción. Por otro lado, el sistema de automatización no podría tener edición gráfica, y en caso de tener edición numérica (en forma de lista), su programación sería terriblemente compleja (debería extraer los datos grabados en cada Transformador según la posición de reproducción de la canción). Además, funciones tipo “Copy”, “Paste” serían realmente imposibles de lograr… ¿Cómo copiar un rango de datos de automatización que se ha grabado al final de un Transformador continuando en el inicio del siguiente? Creo que para tratarse de un environment, el simple hecho de poder grabar y reproducir, enmudecer, escalar o reducir la automatización ya es un logro, así que con eso ya me daría por satisfecho.

Como siempre, el tiempo dirá…