Archivo

Posts Tagged ‘reactivision’

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.

Anuncios

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 III

abril 25, 2010 2 comentarios

waveTable

Desarrollado por Gerard Roma y Anna Xambó del Music Technology Group en la Universitat Pompeu Fabra de Barcelona, waveTable es presentado como:

Un editor de ondas de audio que es operado en tiempo real a través de una interfaz de mesa (tabletop interface). El sistema combina técnicas multi-touch y de interfaz tangible, con el propósito de implementar la métafora de un juego de herramientas (toolkit) que permite la manipulación directa de una muestra de sonido.

Lo resultante, es un instrumento musical adecuado para presentaciones en vivo basadas en la creación de loops de audio que van siendo modificados en el correr del show mediante una interfaz intuitiva que provee feedback tanto al performer como a la audiencia.

Herramientas operando sobre la waveTableEsto último, es uno de los objetivos principales del diseño de YARMI: re-introducir visualmente al espectador en la interacción del músico con el instrumento, algo perdido en la música en vivo generada desde un PC o notebook.

Los autores estudian varios proyectos, desde los orígenes del dibujo de ondas de audio utilizando un lápiz, en el Fairlight CMI, hasta secuenciadores y sistemas similares más recientes: d-touch, Music Table, reactable, scoreTable y Scrapple. A partir de este estudio, observan que estos sistemas principalmente utilizan los objetos tangibles como representaciones físicas de datos (samples, presencia de efectos), dónde manipularlos se traduce a realizar modificaciones en el modelo mismo (sacar un objeto representando un sample en un determinado punto del compás, hace que el sample deje de reproducirse).

Dada esta asignación de significado a los objetos tangibles, sostienen que una gran desventaja es que como los objetos físicos no pueden crear de la nada ni pueden ser duplicados, la naturalieza física de la interfaz restringe la interacción con el sistema. Proponen entonces, en cambio, utilizar los objetos tangibles como herramientas que representen funciones que operan sobre los datos. Así, el conjunto de objetos tangibles se convierten en una serie de herramientas (toolkit), que permiten “esculpir el sonido de una manera conveniente de modo que el diseño de sonido se transforma en un proceso de composición en tiempo real”.

Esto, si bien no es explícitamente considerado en el diseño original de YARMI, puede ser una muy buena idea a aplicar.

El conjunto de herramientas propuesto para operar sobre las ondas de audio, puede verse explicado en detalle en el paper.

En cuanto a la implementación, waveTable tiene una arquitectura de hardware prácticamente idéntica al reactable, dado que utiliza el software reacTIVision como sistema de visión. Además, utiliza SuperCollider para la síntesis de audio en tiempo real. Ambas son alternativas que evaluaremos en su momento para utilizar en YARMI. Los distintos módulos de software, se comunican utilizando protocolos basados en OSC, como el TUIO impuesto por el sistema de visión.

Un video de demostración: