– En la obertura de la obra, los intérpretes graban textos frente a un micrófono y dichos textos son reproducidos posteriormente de forma granulada (desordenada y en fracciones de longitud generalmente mucho menor comparada con la longitud total de la grabación). Los parámetros que controlan el cómo es desordenada la reproducción del archivo están mediados por la tensión muscular de las extremidades de los bailarines.

– En el acto que continúa luego de la obertura, existe una parte dedicada a la emoción de la rabia. En dicha sección, los intérpretes reproducen sonidos de previamente grabados y editados que retratan dicha emoción. La reproducción de dichos sonidos solo responde a movimientos bruscos y la distribución espacial de dichos sonidos en la sala está mediada por los mismos movimientos.

– En el tercer y último acto de la obra existen diversos bancos de sonidos que son reproducidos de forma polifónica y la frecuencia de la reproducción es siempre un múltiplo del pulso cardiaco de uno o más intérpretes. Para reforzar el sonido que se escucha, también existen recursos visuales mediados por el mismo tipo de datos. La construcción total de ambos recursos resulta ser una amplificación del corazón de los bailarines, pero con la mediación artística inherente a la propuesta de Emovere.

A medida que aumenta la cantidad de entradas, unidades de procesamiento y salidas de un sistema, la tarea de obtener un buen resultado sonoro y de administrar la mezcla durante toda la obra se torna cada vez más compleja. Para Emovere se utilizó un total de 58 canales de audio y 37 SO durante los casi 60 minutos de duración de la obra.
Para poder sostener todo el procesamiento que eso involucra hay que tener ciertas precauciones que serán explicadas a continuación:

Si bien durante la obra se utilizaron 58 canales y 37 SO, dichos canales y objetos no estaban procesando información en cada uno de los 60 minutos que dura Emovere. Debido a la cantidad de datos por unidad de tiempo que estaban siendo procesados, no resultaba adecuado crear los objetos justo antes de utilizarlos, ya que las funciones asociadas a la creación de objetos interrumpirían la generación de los 4 canales de audio de salida que se utilizaron en la mayoría de las presentaciones, lo cual significa finalmente la generación de 176.400 muestras de audio en cada segundo y 88.200 si la configuración es estereofónica en lugar de cuadrafónica. Si la generación de audio se ve interrumpida solo por una pequeña fracción de tiempo, el público oirá un corte en el audio.

Por este motivo es que para administrar el uso de CPU de forma adecuada resulta más conveniente montar la obra completa en la plataforma de interacción, pero habilitar una función manual que permita declarar un objeto como ocioso y deshabilite la generación de señal de dicho objeto. En el entorno de Max/MSP esto puede realizarse fácilmente incluyendo cada SO dentro de un objeto poly~ y utilizando el mensaje de mute para habilitar y deshabilitar a voluntad el procesamiento de señal de dicho objeto. Este método fue utilizado en Emovere, habilitando un botón con dicho propósito en la consola virtual existente dentro de la plataforma de interacción.

Otro aspecto importante a tener en cuenta para lograr un buen rendimiento de un sistema de esta naturaleza, es el tamaño de los datos que se están enviando y el impacto que estos tienen en el producto sonoro final. En algunos casos en que una pequeña diferencia en la entrada causará una gran diferencia en la salida, se hace necesario utilizar datos de gran resolución como números de coma flotante, pero otras veces (probablemente la mayor parte del tiempo) no es necesario, ya que basta con una limitada resolución para obtener el resultado sonoro deseado. Resulta un poco complejo ejemplificar este aspecto ya que la variación sonora a la salida de cada objeto puede depender de una o muchas entradas y cada una de ellas puede tener rangos distintos y únicos en cada SO, pero es posible relacionar el aspecto tratado con el nivel de salida de una consola: Probablemente una diferencia de 0.1dBFS no sea significativa al lado de una de 1dBFS. En general, hay que tener en cuenta el compromiso que existe entre la frecuencia a la que llegan los datos y el peso individual de cada dato. En 10 o en 100 datos, que estos sean enteros o de coma flotante podría no ser demasiado significativo, pero cuando estamos hablando de miles de datos por segundo, la diferencia es realmente importante y crucial a la hora de diseñar un sistema como el utilizado en Emovere.

Junto con el punto anterior, también es necesario tener en consideración la prioridad de los datos. Max/MSP hace una diferencia entre los datos que son parte de una señal de audio y los que no, así como también en la manera en que operan los objetos dentro del programa asociados a este tipo de datos. Los objetos que generan señal son operados por el DSP de Max/MSP mientras que los que no, se distribuyen en eventos de alta y baja prioridad, siendo cualquiera de estos dos últimos, menos prioritarios que las señales, al menos que se altere intencionadamente la configuración de Max/MSP. Nuevamente este punto es bastante complejo, ya que no existe una regla que siempre funcione para el tipo de interacciones como las que utilizamos en Emovere y por lo tanto la prioridad de los datos debe ser analizada caso a caso. A modo general, los cuatro parámetros cuyo manejo fue clave para diseñar la plataforma de interacción son: El modo Overdrive, SIAI (Schedule in Audio Interrupt) y los objetos defer y deferlow.

De la misma forma que cuando uno escoge el camino más corto para llegar a destino, es necesario proveer el camino más corto posible a cada mensaje ya sea MIDI u OSC. Para la plataforma de interacción se programó una sección exclusiva dedicada a manejar los mensajes. Existen mensajes que llegan a secciones de procesamientos complejos que no se utilizarían normalmente en una función de la obra y que ejecutan funciones de forma remota tales como crear un SO y otros que deben ser entregados con rapidez y rigurosidad temporal tales como el control de nivel de salida de un SO que es modulado por alguna extremidad de los intérpretes. La sección dedicada a la administración de mensajes dentro de la plataforma de interacción abrirá un puerto exclusivo para mensajes de alta prioridad y otro para mensajes de baja prioridad. A su vez, los mensajes de alta prioridad son distribuidos al respectivo SO sin ninguna mediación adicional de algún script o líneas de código adicionales, haciéndola lo más rápida posible.

Además de todo lo ya mencionado, existen parámetros que son de vital importancia y que están relacionados con la manera en cómo son procesadas las señales dentro de la plataforma de interacción y en última instancia, dentro de Max/MSP. Como ya fue mencionado, la frecuencia de muestreo hará la diferencia en la cantidad de datos que deben ser procesados por el sistema y también deben coincidir con la frecuencia de muestreo a la cual son almacenados los archivos en los objetos buffer~, de otra forma podrían haber problemas de afinación. En cuanto al vector de audio, existe el I/O Vector y el Signal Vector. El primer parámetro tiene relación con la cantidad de datos que empaquetará por vez Max/MSP para realizar las operaciones de entrada y salida, mientras que el segundo tiene que ver con la cantidad de datos que empaquetará Max/MSP para realizar las operaciones que ocurren luego de la entrada y antes de la salida. Existe un compromiso por lo tanto entre precisión y uso de procesamiento, ya que mientras mayor sean los vectores, el procesamiento usado será menor pero existirá un retardo más evidente entre la entrada y la salida a que si por el contrario los valores de los parámetros son pequeños y en dicho caso habrá un retardo menor pero un procesamiento más intenso.