Esta es la parte que más me gusta diseñar: la creación de las rutas que el usuario debe seguir para lograr su propósito. El mundo de la informática musical está repleta de excelentes interfaces de usuario (GUI), por ejemplo el magistral Reason con el concepto de rack virtual, el curioso interface de Ableton Live o la súper-configuración del GUI de Cubase. Cito estos pero en realidad podría citar cientos de plug-ins con genialidades en la forma en que permiten ser manejados. Lógicamente hay límites que el Environment no puede simular, no puedo crear un interface de usuario que esconda partes para luego volver a mostrarlas, o permitir redimensionar sus elementos. Pero dentro de las severas limitaciones del Environment (es lógico, nunca fue diseñado para crear aplicaciones musicales), es posible lograr resultados muy realistas y sobretodo prácticos.
El cometido básico de un interface de usuario es el de mostrar y editar el contenido de las memorias internas. Cualquier editor MIDI de Cubase, Logic o cualquier secuenciador hace exactamente eso. Es más, todo el programa entero, la parte “visible”, se dedica a mostrarnos la información que hemos creado, ya sea un procesador de textos, un procesador de imagen o un procesador de audio, como nuestros queridos secuenciadores / plug-ins.
Particularmente me gustan los interfaces de usuario que únicamente muestran la información que es susceptible de ser editada en ese instante. Por ejemplo, en el excelente sintetizador FM8 de Native Instruments se nos muestran los parámetros de cada operador de la síntesis FM de forma individual. ¿Para qué ver los datos del primer operador si estamos editando el segundo?, ¿para qué rellenar la pantalla con más datos y cajas que solo nos perturbarán?
Poder esconder datos irrelevantes es una virtud, pero también una necesidad. En Reason puedo encoger los dispositivos que en ese instante no son el objetivo de mi edición. Así ahorro espacio en pantalla pero además no debo estar viendo controles innecesarios que ya he programado y que no pienso editar en ese instante.
Este tipo de interfaces de usuario funcionan conmutando la información del dispositivo o área seleccionada. Por ejemplo, en REQUIEM hay 8 sintetizares virtuales con todos sus parámetros, modulaciones y 128 patrones encadenables. Es absurdo mostrarlo todo en una única pantalla, aunque desde el punto de vista de programación es algo mucho más cómodo y sencillo.
En cambio, cada vez que selecciono uno de los sintetizadores, REQUIEM cambia el color de los controles mostrados según el color del sintetizador seleccionado, y “escupe” los estados de los controles y parámetros de ese sintetizador seleccionado. Pero los otros sintetizadores deben seguir operando “por detrás” (en background), es decir, REQUIEM debe continuar sonando sin importar lo que seleccione en el interface de usuario. Esto requiere de dos rutas principales de datos: los datos reales salientes y los datos del dispositivo virtual seleccionado en ese instante, que deben ser enviados a la “salida” y además mostrar valores en pantalla para permitir su corrección. Así pues hace falta seleccionar el dispositivo (por parte del usuario) y REQUIEM “disparará” los datos pertinentes (usando rutinas de disparo de eventos, de las cuales ya he citado su más importante exponente: meta-evento 99 con valor 0)
El Environment contiene un curioso objeto llamado Alias, que “clona” el aspecto y definición (contenedor en E-Code) de otro objeto que sea de su mismo tipo. De esta forma puedo lograr que un objeto fader tenga un color y tamaño, pero que a pulsar un botón éste se convierta en una caja numérica de otro color y tamaño, modificando además el tipo de evento que puede recibir y/o enviar. Además puedo asignar varios objetos “master”, por ejemplo 5 tipos de faders, e ir conmutando del uno al otro (con el uso de Asignadores de Alias, un objeto Alias y los objetos empleados como modelos).
El Fader resaltado es en realidad un objeto Alias que toma la definición del evento a enviar /recibir y el aspecto gráfico de los objetos conectados a partir de la segunda conexión del Alias Assigner. Observa que ahora el Alias se comporta como el Fader 1 gris inferior, y envía control 7 por el canal 1 (ver Monitor). El valor 100 es la posición actual del Alias. La línea azul delgada enlaza el Alias con el objeto a clonar: es un sencillo indicativo.
Ahora hemos conmutado el Alias Assigner y el Alias superior toma el aspecto y definición del Fader rojo, que envía control 7 por el canal 3. Moviendo el Fader Alias ya no se enviará control 7 por el canal 1, sino que la definición cambia siendo clonada del Fader 3 rojo.
Hemos conmutado el Alias Assigner al Fader 2, definido como control 7 por el canal MIDI 2. Veamos los parámetros del objeto Alias. Podemos indicar que "tome" al nombre del objeto original, que el tamaño coincida o que pueda re-dimensionarse libremente, o re-canalizar los eventos procesados por el Alias.
Ahora veamos el Alias Assigner... en realidad es un conmutador que permite indicar qué conexión se tomará como activa. En la conexión superior se conecta el objeto Alias, y en las siguientes los objetos a clonar. Además el Alias Assigner cuenta con su propia definición de entrada y salida, con lo que podemos controlarlo remotamente. En este caso he creado otro fader que cambia la conmutación de Alias Assigner con un evento de control 7.
Pero por desgracia el uso de los Alias es muy limitado. No puedo usar Alias en Macros, es decir, nunca podré crear una Macro cuyos faders cambien de aspecto dinámicamente. Tampoco puedo convertir un objeto Fader en un objeto Teclado Virtual… sólo puedo conmutar entre objetos del mismo tipo, por ejemplo un objeto retardo con un tiempo de retardo convertido a otro objeto de retardo con otro tiempo de retardo distinto. Pero además hay otras severas limitaciones, hay objetos imposibles de clonar, por ejemplo conmutar entre dos objetos Monitores de distinto tamaño… Y lo más importante: cuando un Alias cambia de aspecto provoca un redibujado de pantalla, Logic actualizará la ventana del Environment automáticamente, así que se producirá un breve parpadeo. Un último detalle, el uso masivo de Alias no es bueno, carga mucho la capacidad de proceso del Environment. No es aconsejable crear todo un interface de usuario únicamente con Alias, eso sería llenar la pantalla con cientos de objetos Alias que Logic debería redibujar constantemente: hay que usarlos sabiamente.
Aún así, el uso de objetos Alias es imprescindible para el diseño de REQUIEM, así que he tratado de exprimir al máximo su uso, tratando de lograr una experiencia de uso lo más cercana posible al de un software “normal”.
No hay comentarios:
Publicar un comentario