El diseño actual de YARMI

julio 13, 2011 Deja un comentario

Luego de meses de desarrollo estamos llegando a la etapa final del proyecto. YARMI es ahora una aplicación funcional, con un conjunto de características interesante, pero que podrá expandirse mucho más en un futuro. Con el fin de cerrar la tesis de grado de nuestra carrera, fue necesario precisar y congelar este conjunto de características, a pesar de la gran cantidad de mejoras e ideas nuevas que quedaron pendientes. A continuación describiremos su funcionamiento actual. El texto fue extraído de el paper que presentaremos al evento AES LAC 2011 que tendrá lugar en Montevideo, Uruguay a fines de Agosto de este año.

 

El instrumento

El instrumento consta de una o varias estaciones. Una estación consiste en una superficie de trabajo, un conjunto de fichas de madera, una cámara, una computadora y, potencialmente, un proyector. Cada estación es operada por uno o varios músicos interactuando con ella por medio de sus interfaces tangible y visual.

El instrumento musical es colaborativo tanto dentro de una misma estación –debido a que las fichas pueden ser manipuladas por más de una persona– como al formar la red de estaciones: el instrumento puede mantenerse en comunicación con otras instancias cercanas para hacer música en conjunto, de una forma coherente.

 

La interfaz tangible y la salida visual

La interfaz tangible está formada por un conjunto de fichas de madera (tokens) con marcadores visuales reconocibles por el sistema (fiducials) pegados en una de sus caras y símbolos identificables por un ser humano en la otra. Estas fichas son manipuladas por el músico, y su ubicación y rotación dentro del espacio de trabajo son captadas por el sistema mediante una cámara.

La salida visual de la interfaz se construye en base a la información recibida a través de la interfaz tangible, y puede proyectarse sobre una superficie grande, visible tanto para el músico como para la audiencia.

En la superficie de trabajo se presentan distintos secuenciadores musicales –que llamamos pistas– y máquinas de efectos de sonido de tiempo real, que serán operadas por los músicos para generar la salida de audio esperada, en sincronía con la de los músicos de las demás estaciones.

 

Pistas

YARMI cuenta con dos tipos de pistas, que se crean utilizando dos tokens particulares: con la rotación del StartToken se selecciona el tipo de pista deseada y cuando un EndToken aparece en el área de trabajo, la nueva pista se crea.

Las pistas representan un compás de cuatro pulsos (o beats), que pueden subdividirse en hasta cuatro partes –modificando el parámetro de cuantización, mediante la rotación del EndToken– transformándola en un secuenciador de dieciseis pulsos.

Moviendo sus tokens de comienzo y fin, una pista puede reposicionarse en el área de trabajo. También puede colapsarse sobre un StartToken; esto es, llevarse a un estado en el que el área que ocupa es mucho menor y con solo ocultar o volver a mostrar el token, la pista detiene o reinicia su reproducción, proveyendo de esta forma un método de secuenciación manual.

La forma de componer sobre una pista depende de su tipo. Una pista de muestras funciona colocando SampleBankTokens –esto es, tokens que representan bancos de muestras– en sus ranuras. Con la rotación de cada uno de estos tokens se modifica la altura tonal de la muestra seleccionada, mientras que con ayuda del SelectorToken –que se mencionará más adelante– se elige la muestra a reproducir.

Una pista de sintetizador funciona con la ayuda de tres tokens adicionales, que permiten al músico asignar una nota particular a cada ranura, o eliminarla. El sonido generado por esta pista es básico: una onda de diente de sierra con una envolvente de amplitud predeterminada. Sin embargo, con ayuda del MIDIToken puede hacer que su salida se redirija por un canal MIDI para poder ser interpretada por un software externo.

Finalmente, las pistas pueden ser eliminadas utilizando el DropToken.

 

Loops

El instrumento soporta la secuenciación continua y en bucle de un tipo particular de muestras, llamadas loops. Éstas son generalmente piezas rítmicas pregrabadas a una velocidad (BPM) particular, que se extienden sobre una cantidad determinada de compases.

Un LoopBankToken contiene un banco de loops previamente configurado. Con solo colocarlo sobre la mesa, la reproducción del primer loop del banco comienza. La selección del loop y de la altura tonal con el que este se reproducirá se realiza de la misma manera que para un SampleBankToken.

Gráficamente, un token de loop es muy similar al de una pista colapsada, permitiendo que la secuenciación de ambos tipos de construcciones se pueda realizar intuitivamente mediante el mismo mecanismo.

 

Control

No se ha mencionado hasta ahora una funcionalidad importante del instrumento: la capacidad de detener o reanudar la composición completa de la estación utilizando un token algo particular –un token con un fiducial de cada lado– que según la cara que muestre a la cámara, ejecutará uno u otro comando.

Otro token importante es el BPMToken, que controla la velocidad de reproducción de la composición entera: tanto pistas como loops ajustan en todo momento su velocidad de reproducción al valor que este token modifica.

Antes de introducir el próximo token, es necesario introducir el concepto de acoplabilidad, la capacidad de un token de asociarse a un objeto particular de la interfaz para afectarlo de una u otra manera.

El VolumeToken controla con su rotación –en su modo de funcionamiento normal– el volumen general de la estación. Sin embargo, este token puede también acoplarse a pistas, tokens de loops y tokens individuales dentro de una pista de muestras para cambiar volúmenes específicos.

Por último, existe además un token similar al anterior que permite controlar el balance estéreo de la salida de audio general.

 

Efectos

Los EffectTokens son tokens que pueden ser acoplados tanto a pistas como a tokens de loop para modificar la salida de audio que estos objetos generan. Si el token no está acoplado a ningún objeto, la salida de audio que se ve afectada es la global de la estación.

Actualmente están soportados tres tipos de efectos: reverb, tremolo y delay. Una vez que el token de efecto está en el área de trabajo, mediante su rotación y con la ayuda del SelectorToken pueden modificarse –con resultados en tiempo real– sus parámetros.

 

Herramientas

Si bien hasta ahora no se ha mencionado explícitamente, varias de las funcionalidades descritas utilizan el concepto de dimensión: un parámetro que ciertos tipos de tokens –los tokens dimensionables– poseen y que toma un valor dentro de un conjunto discreto de posibilidades (que varía de token a token) y según el cual modifican su comportamiento de alguna u otra forma.

El SelectorToken permite, mediante el mecanismo de acoplamiento combinado con su propia rotación, modificar la dimensión seleccionada en un token.

Los tokens dimensionables son: SampleBankToken, LoopBankToken y EffectToken. A todos ellos puede acoplarse el SelectorToken para modificar su dimensión seleccionada –que para los dos primeros es la muestra seleccionada y para el último, el parámetro del efecto que la rotación del token original modifica.

 

Características de red

Como se mencionó anteriormente, el instrumento tiene la capacidad de funcionar en conjunto con otras estaciones YARMI en forma coherente.

En este escenario, la estación líder –la última estación que haya puesto el LeaderToken sobre su mesa– tiene el control sobre la producción musical global, pudiendo decidir cuando ésta se detiene o reinicia, y especificando parámetros como el volumen general, BPM y el balance estéreo.

 

 

Esto es todo por ahora. En breve publicaremos videos del instrumento en acción, reseñas sobre la implementación de la aplicación e ideas o características que podremos seguir trabajando en un futuro.

Anuncios
Categorías:Diseño Etiquetas: , ,

La PlayStation®Eye

junio 11, 2010 1 comentario

Hasta hace poco veníamos usando una cámara web prestada por nuestro tutor, la PS3 Eye, desarrollada por Sony para su consola PlayStation 3. Según nos comentaron, esta cámara es muy utilizada para sistemas de visión por computadora por presentar distintas características que la hacen muy superior al resto de las cámaras USB del mercado, siendo capaz de proveer en teoría hasta 60fps a una resolución de 640×480 pixels y 120fps a 320×240 pixels.

Exclusivamente para Windows, existen unos drivers desarrollados por Code Laboratories que permiten alcanzar 640×480@30fps (por compatiblidad con muchos de los programas que utilizan cámaras web en Windows). Esta empresa también provee, gratuitamente, un SDK para obtener 640×480@60fps (la cual se podría utilizar desde nuestro código modificado del reacTIVision, en Windows, para mejorar el framerate).

PS3 Eye

La PS3 Eye

Recientemente encontramos un artículo muy interesante en el que se explica qué es lo que hace a esta cámara superior al resto y por qué sería difícil encontrar una mejor (restringiéndonos al estándar USB 2.0 actual).

Básicamente, la cámara brinda la opción de enviar el video sin comprimir (RAW), lo que hace que se minimice la latencia (tiempo entre que la imagen “ocurre” y está disponible para utilizar en la PC). Entregar 640×480@60fps en formato RAW está al límite del ancho de banda que se puede lograr con USB 2.0, por lo que sería inútil esperar una cámara USB 2.0 con mayores prestaciones que garantice una baja latencia.

Actualmente estamos intentando conseguir una de estas cámaras para uso exclusivo nuestro. Luego, sería necesario ver cómo hacerla funcionar en las otras platafromas que intentaremos soportar (Linux y Mac OSX).

Categorías:Hardware Etiquetas:

Captura exclusiva del video por reacTIVision

Un problema que presenta reacTIVision respecto a ARToolKit, es que al acceder a la cámara desde su propio ejecutable (que se comunicará con nuestra aplicación por medio de un socket) un segundo proceso (nuestra aplicación) no tendría acceso, en principio, a la imagen original por ya estar siendo consumida.

Poder utilizarla podría ser interesante por ejemplo para agregarla a la salida visual de nuestra aplicación, dibujando la interfaz de usuario “aumentada” sobre la imagen capturada original, en caso de no estar usando un proyector. Utilizando ARToolKit esto no es un problema, dado que la herramienta se presenta en forma de una librería cuya funcionalidad se accederá (básicamente) invocando a una función que recibe un frame de imagen como parámetro y devuelve la información sobre la ubicación de los fiducials. En este escenario, la imagen puede utilizarse posteriormente como se quiera.

Por esto, antes de continuar quisimos estudiar la factibilidad de poder acceder a esta imagen también desde nuestra aplicación. Investigando un poco, encontramos software como SplitCam para Windows, que crea una segunda cámara virtual con la misma imagen que captura la original. Si bien podríamos buscar aplicaciones similares para las otras plataformas que intentaremos soportar (Mac OSX, Linux) preferimos encontrar una solución que sea en cierta medida independiente de la plataforma.

Para esto, estudiamos los fuentes del reacTIVision y encontramos el lugar donde la imagen es obtenida de la cámara y comenzada a procesar. La idea sería entonces tomar esa imágen antes de continuar el procesamiento y hacérsela llegar una aplicación externa.

La primer idea fue enviar el frame de video a una aplicación de ejemplo en openFrameworks utilizando OSC, ya que este será el protocolo de comunicación utilizado por los distintos módulos de nuestra aplicación. Para eso, se extendió el addon ofxOSC de openFrameworks para soportar el tipo de datos blob y poder enviar información binaria. Debido a la restricción de tamaño de los paquetes UDP (protocolo sobre el que se implementa OSC en ofxOSC), fue necesario dividir cada frame en una serie de mensajes de OSC enviados por separado, uno para cada línea horizontal de imagen.

El resultado de esta implementación no fue positivo: un gran porcentaje de los paquetes se perdían y los frames llegaban a la aplicación con una velocidad mucho menor (unos 10fps) a la que se generaban:

Fue ahí que hicimos el siguiente cálculo: estábamos intentando enviar 640 * 480 (resolución) * 3 (bytes por pixel en color 24-bits) * 30 (fps) = 26,4 MB/s utilizando los servicios de red. Sin mucha esperanza, hicimos una prueba adicional intentando enviar esa información por TCP y obteniendo resultados también negativos: si bien los paquetes ya no se perdían por ser TCP un protocolo que resuleve este problema, los frames tampoco llegaban en tiempo real.

La tercer alternativa, que finalmente tuvo éxito, fue utilizar memoria compartida entre procesos para hacer una copia del frame obtenido y poder accederlo desde nuestra aplicación. Para esto, se utilizó la librería multi-plataforma POCO (ya incluida en openFrameworks y que agregamos al proyecto de reacTIVision) compartiendo un mismo segmento de memoria entre el módulo reacTIVision (que realizaría la escritura) y nuestra aplicación (que leería la información escrita). La implementación resultó ser eficiente, entregando los frames en tiempo real y prácticamente sin variar la utilización del CPU.

Trackmate

Trackmate es una de las opciones disponibles para utilizar como framework de visión, en la construcción de YARMI. Es un sistema de reconocimiento de fiducials desarrollado por el Tangible Media Group del MIT Media Lab, con el objetivo de ser económico y fácil de construir. Trackmate reconoce la posición, rotación e información de color de objetos etiquetados y dispuestos sobre una superficie. Envía toda esta información a las aplicaciones cliente mediante el protocolo LusidOSC (basado en OSC como su nombre sugiere), desarrollado por los autores.

El mayor fuerte de este framework, es la excelente documentación que posee y su presentación desde un sitio web muy bien diseñado y con un alto grado de usabilidad. En la página se puede ver distintos ejemplos de aplicaciones que utilizan el framework.

El sistema es capaz de reconocer una clase de fiducials especial, que permite manejar alrededor de unos  280 trillones de identificadores diferentes (códigos de barra circulares) de 1” (una pulgada) de diámetro.

Del sitio web, pueden descargarse las siguientes herramientas:

  • Tagger: permite generar las etiquetas que el sistema puede reconocer, exportándolas en formato PDF o PNG.
  • Tracker: es el módulo principal, que recibe la información de la cámara web especificada y publica un servidor dónde espera conexiones de clientes que hablen el protocolo LusidOSC. Además, tiene integrado el mecanismo de calibrado y testeo.
  • LusidOSC Bundle: conjunto de aplicaciones de ejemplo para ejecutar en Processing y probar el sistema fácilmente. Además, incluye una librería para Processing, que resuelve la comunicación entre programas desarrollados en este entorno y el servidor (Tracker).

El sistema prometía mucho, pero una vez iniciada la etapa de calibrado y testeo, se hicieron evidentes una serie de restricciones importantes.

Los parámetros más importantes a la hora de configurar el sistema son las dimensiones del área de trabajo, la resolución de la cámara y la cantidad de pixels (de cámara) por pulgada (de superficie).  La primer restricción que se observó, es que para un área de trabajo aplicable a nuestro proyecto, la taza de cuadros por segundo de información que el sistema puede generar no es suficiente. En la siguiente tabla puede verse su variación en función del área:

dimensión del área (pulgadas) cuadros por segundo
11.625 x 8.250 15
6.000 x 6.000 20
3.000 x 3.000 30

Se puede notar que recién para una relación fiducial-área de 1/9, el sistema provee una taza de cuadros por segundo razonable.

Otra restricción encontrada, es que el sistema es muy suceptible a cambios en la iluminación. Durante la etapa de calibrado, una vez que se fijan los parámetros arriba mencionados, es necesario realizar la “calibración de blancos”. Se puede notar como la imagen pre-procesada por el sistema se deteriora considerablemente por el más mínimo cambio en la iluminación, respecto a aquella con la que se realizó el calibrado.

Asociado a esto último, se notó que el sistema está construido para recibir una imagen formada solamente por el fondo blanco y los fiduciales. Cualquier otro objeto captado por la cámara dentro del área de trabajo (como un soporte para el fiducial, o una mano) hará que el sistema falle. En particular, el valor de las rotaciones de los fiducials es lo primero que se pierde por completo.

Tras el análisis del sistema, se concluye que éste está más orientado a un escenario con las siguientes características: libre de objetos que interfieran en la imagen (por ejemplo para flimarse desde abajo de la superficie, como se hace en la Reactable), con un área de trabajo relativamente chica, y en dónde tener tal cantidad de fiducials distintos pueda ser de utilidad.

El framework no cumple con los requisitos adecuados para nuestra aplicación, por lo que fue descartado.

ReacTIVision VS D-touch

Tanto ReacTIVision como D-touch son sistemas para el seguimiento de la ubicación y la orientación de marcadores (fiducials) en tiempo real.

ReacTIVision surge como una continuación de d-touch principalmente debido a los bajos tiempos de los frame rates alcanzados con d-touch.

D-touch utiliza una topología única para todos los fiduciales en un set.

El set consta de 120 fiduciales únicos que se diferencian mediante un código de permutación expresado por el número de hojas negras en el grafo de adyacencia. En el siguiente ejemplo el código de permutación es  (1,2,3,6,5,4).

d-touch asocia el código de permutación de las regiones de hojas negras a un conjunto específico de fiduciales.

En segundo lugar, el d-touch original no prescribe un determinado método para calcular la ubicación y orientación de los fiduciales.

Por último, las geometrías simples de los fiduciales (que por cierto tienen la ventaja de ser fácilmente dibujados a mano) no fueron diseñados para minimizar el tamaño de los mismos.

Por otra parte el sistema de reacTIVision admite conjuntos de fiduciales de distintos tamaños y topologías sin ningún cambio de código.

Consideramos que esta es una mejora significativa respecto a d-touch en nuestro contexto, donde queremos experimentar con fiduciales más pequeños.

El set consta de 128 fiduciales exclusivos, logrando tener una superficie del casi 50% menos que las del set de 120 fiduciales de d-touch.

A continuación mostramos una comparación de performance entre las diferentes librerías.

Figura 1

La figura 1 compara el uso de la CPU y el frame rate obtenido con reactTivision (libfidtrack) y dos versiones de d-touch: una versión reciente (libdtouch) y la versión original (dtouch_old)

Podemos ver que la actual implementación de reacTivision es 4 veces mas rápido que la versión actual de d-touch y mas de 16 veces mas rápido que la versión original.

Podemos resumir entonces las mejoras conseguidas por la reacTIVision frente a d-touch en tres áreas:

Funcionamiento, tamaño de los fiduciales y escalabilidad para diferentes topologías de fiduciales y tamaños establecidos.

Categorías:Estado del Arte

Estado del Arte VI

Audio d-touch

Es un sistema desarrollado por Enrico Costanza, S.B. Shelley y J. Robinson del Media Engineering Group la University of York (York, UK) en el 2003, y presentado como una “interfaz de usuario tangible para la composición y performance de música“.

Para su demostración, se implementaron tres aplicaciones musicales distintas: Augmented Musical Stave, Tangible Drum Machine y Physical Sequencer. Las dos últimas continuaron siendo mejoradas después de su presentación y actualmente se pueden descargar de la web official del sistema, junto con muy claras instrucciones sobre cómo construirlo y probarlo uno mismo.

La configuración general para las tres aplicaciones es la misma: está compuesta por un área interactiva y un conjunto de bloques marcados. El área es una superficie plana observada por una webcam (sostenida por el soporte de una lámpara de mesa) conectada a un PC, de la cual no se necesita el monitor.

El feedback al usuario es provisto tanto por el audio como por la disposición física de los bloques (que actúan como dispositivos de entrada y salida). El área interactiva, está cubierta por una hoja de papel con cuatro marcadores especiales en las esquinas, que son utilizados por el sistema para el calibrado automático, y algunas marcas visuales destinadas al usuario.

En cuanto a la implementación del sistema lo más interesante es el sistema de visión, el cual fue precursor del reacTIVision. Básicamente permite al implementador diseñar sus propios marcadores, de forma que tengan algún sentido para el usuario. Además, es posible construir el sistema en distintos tamaños, con la única restricción impuesta por la resolución de la webcam que determina la relación que se debe mantener entre el tamaño del área interactiva y el de los objetos. Hablaremos de este sistema más adelante ya que será uno de los posibles frameworks de visión a utilizar. La síntesis de audio se realiza utilizando el Syntehsis ToolKit (STK).

Parte del trabajo de los autores, fue testear las aplicaciones con un conjunto de usuarios con distintos grados de formación musical. Si bien obtuvieron mayormente resultados positivos, algunos usuarios señalaron que muchas veces les fue difícil saber que punto del loop estaba siendo reproducido en un momento dado, y que esto podría ser resuelto agregando feedback visual o de audio, extra. Esto es algo que también notamos al probar el sistema y es algo que el diseño de YARMI tiene en cuenta, por lo que será interesante evualuar el resultado en este sentido luego de construido.

Como trabajo a futuro, sugieren adaptar la interfaz para su utilización contra un instrumento de tiempo real genérico. Esto es, generar una salida de audio en algún protocolo estándar (como MIDI u OSC) para controlar aplicaciones de audio como Ableton Live o módulos desarrollados en PD o Max/MSP. Si bien YARMI va a estar comunicándose con un módulo PD o similar utilizando alguno de estos protocolos, queda a definir si va a ofrecer soporte para aplicaciones del estilo de Live, algo que sería muy interesante.

Las aplicaciones

A continuación se describen brevemente las tres aplicaciones y se muestran algunas imágenes del sistema armado por nosotros.

La primer aplicación mencionada es la Augmented Musical Stave, la representación física de un compás en partitura clásica sobre la que se dispondrán los distintos marcadores que simbolizan notas y silencios de diferente duración (blancas, negras, corcheas, semicorcheas…). La altura determina, así, la nota a reproducir.

La segunda aplicación es la Drum Machine, un secuenciador de sonidos de batería en loop. Existen dos tipos de marcador para las intensidades de sonido alta y baja. La altura en el compás indica el sonido de batería a reproducir.

La última aplicación es el Sequencer, donde los usuarios pueden grabar audio de entrada (conectado a la tarjeta de sonido) y asignándolo a los distintos bloques, que luego podrán ser reproducidos en algún punto del compás. La altura en el mismo representa para esta aplicación el volumen del sample. Es posible luego agregarle distintos efectos preestablecidos a la pista.

La diseño de la interacción para las tres aplicaciones está muy bien trabajado. Puede leerse con más detalle en el paper original.

Estado del Arte V

abril 30, 2010 1 comentario

AudioPad

AudioPad es una interfaz tangible para hacer musica en vivo. El centro del estudio es encontrar una manera simple y poderosa de interactuar con el secuenciador a través de la interfaz tangible, permitiendo una comunicación mayor entre el performer y el público.

El performer comienza mapeando piezas con grupos de sonidos, poniéndo las piezas sobre los grupos de sonidos mostrados en una esquina del espacio de proyección.

El volúmen es regulado con la rotación de la pieza. Después, utilizando una pieza especial (el “Selector”) se puede seleccionar qué sonidos reproducir.

Presionando el botón que tienen las piezas se despliegan los parámetros de efecto, y moviendo la pieza se modifican contínuamente sus parámetros.

El sistema de tracking de las piezas (basado en Sensetable, un proyecto previo de Patten) es de radio frecuencia en vez de procesamiento de imágenes.

La implementación de AudioPad envía señales MIDI al software Ableton Live, quien se encarga de la síntesis y reproducción del sonido. Estas señales son: disparar nuevos sonidos y hacer cambios en volúmenes o parámetros de efectos.

Fue desarrollado por Patten, Recht e Ishii del MIT Media Lab, Cambridge, Massachusetts.

Link al paper.

Un video de uno de los autores contándonos sobre el sistema:

Categorías:Estado del Arte