E-Code Lección 1 – Área de trabajo

Antes de comenzar, hay que resaltar que es imprescindible conocer de forma muy profunda la naturaleza de los eventos MIDI. No me refiero a la conversión a binario o hexadecimal de los bytes que componen un evento MIDI, sino a saber exactamente qué es un evento de control, las diferencias entre aftertouch polifónico o de canal, que es un MSB y LSB, cómo se compone un evento de nota, y un largo etc. Afortunadamente en la red encontrarás mucha información al respecto.

Pero además también es indispensable la necesidad de dominar el Environment y sus objetos, pues será con ellos con los que armaremos nuestro querido dreamsynth (equipo de ensueño). En este caso también encontrarás bastante información en la red, aunque la más fiable siempre proviene del manual de Logic / Logic Pro. Yo comencé con esa documentación, lo cual indica que es perfectamente válida para cualquier usuario.


Límites del código:

Logic 5 permite el uso de poco más de 8000 objetos en el Environment. Ignoro si este límite se ha incrementado en las presentes versiones de Logic / Logic Pro. Como uso la versión 5 para Windows, ese será mi límite final: toda la funcionalidad de REQUIEM debe operar con 8000 objetos Environment. ¡No caben más!

La segunda limitación del Environment se refriere a su “ancho de banda”. Aunque es muy potente, el Environment no soporta muy bien el envío masivo de datos. Puedo procesar 20 eventos por una matriz de objetos simultáneamente, pero no centenares de ellos. Si creo 100 faders conectados a un mismo objeto disparador (trigger, el meta evento 99 con valor 0… ya hablaremos de ello, no te preocupes) el resultado al efectuar el disparo de valores de esos 100 faders no serán 100 disparos. Algunos “se perderán”, simplemente dejarán de operar no devolviendo ningún valor. ¿Cuántos funcionarán? Depende básicamente de todo: el equipo usado, la propia programación del Environment, el driver de audio empleado… ¡todo!

¿Cómo superar esos dos límites?

Para el primero hay una única solución posible: Macros. Se trata de empaquetar procesos secuenciales en un único objeto llamado Macro. Así, dónde antes habían 30 objetos ahora sólo habrá uno. Pero las Macros del Environment también tienen una limitación: soportan poco más de 100 objetos, y si estos son del tipo fader de texto todavía menos. Esto indica que los Macros están limitados por memoria, pueden caber 100 faders numéricos, pero no 100 faders de texto ya que éstos almacenan además de su propio valor 128 cadenas de texto asociados a cada valor, lo cual supera sustancialmente la memoria empleada por un simple fader que no sea de texto, que solo debe almacenar el valor actual. Por último, las Macros requieren de una entrada y una salida (una puerta de entrada y una salida). Pero por ellas pueden “pasar” múltiples tipos de datos simultáneamente o secuencialmente. Ya dedicaré un post extenso a las Macros, pues son la base de la programación en E-Code.

Ejemplo de Macro creado en el Environment. Consta de 32 objetos tipo fader numérico, con un transformador de entrada y salida.

El mismo Macro pero con 32 faders tipo texo (en vez de números podrían aparecer letras o cadenas de textos) Aquí Logic se queja, no es posible crear el Macro ya que este tipo de faders requiere más memoria. Lamentablemente, el Macro no podrá ser creado.

Para el segundo límite, el ancho de banda, también hay una única solución posible: secuenciar los procesos, es decir, que éstos no ocurran simultáneamente. En el ejemplo indicaba que no es posible disparar simultáneamente 100 faders y que el resultado de ese disparo será que algunos valores “se perderán”. Puede solucionarse insertando un objeto de retardo (Delay), ajustándolo a un retardo pequeño, insignificante. Cada grupo de 10 faders podría estar disparado con un retardo insertado, así lograríamos obtener losa 100 disparos y no se perdería información. Lamentablemente esto tiene un coste: el secuenciador de Logic necesita estar reproduciendo, es decir, el control “Play” pulsado y el reloj corriendo. Esto determina algo vital: REQUIEM sólo funcionará cuando Logic esté en reproducción. De otra forma, ¿cómo podría el Environment procesar datos en el tiempo sin tener un reloj corriendo?

Motor de patrones de REQUIEM. Como puedes ver hay varios objetos retardo (icono de reloj) que se encargan de establecer el orden de ejecución. Uno de ellos está seleccionado, puedes ver sus parámetros en la caja de parámetros de la izquierda. Observa que hay muchos objetos Macro, que son reconocibles gracias al borde de color oscuro de su alrededor.

Hay tres objetos básicos que requieren que Logic esté en reproducción / grabación (es decir, con el reloj corriendo):

• El objeto retardo (Delay).
• El objeto TouchTracks.
• El objeto arpegiador.

En el caso del retardo, si le hemos indicado que deje pasar la señal original recibida por su entrada, ésta saldrá por la salida aunque el reloj de Logic esté detenido, pues es una señal que no va retardada. Pero los eventos duplicados por los retardos del objeto retardo sí requerían del reloj de Logic.

Y por último, aun nos queda un límite… ¡nosotros! Es imposible programar en E-Code si no se sabe programar conceptualmente, es decir, saber dividir cada tarea en unidades de proceso individuales. Dicho de otra forma: saber traducir lo que queremos lograr al lenguaje de objetos del Environment.

¡Anda… Ya estamos en 2010 y yo sigo rodeado de cables y transformadores…!

Buenos tiempos para todos…

Proceso de creación de un Macro. Lo que estás viendo es un LFO que permite dibujar la forma de onda y que la repite infinitas veces generando una modulación.
Como puedes ver todo el proceso envía el resultado a través del transformador "OUT" que actúa como puerta de salida.

Macro empaquetada: todos esos objetos han sido reducidos a un único objeto.