Archivo

Archivo del autor

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.

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.

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:

Estado del Arte I

abril 20, 2010 1 comentario

Arrancando a ver un poco qué proyectos de temática similar a la de YARMI hay en la vuelta, encontramos la web de Martin Kaltenbrunner (uno de los creadores de la Reactable), que nos facilita una larga lista de proyectos relacionados con interfaces tangibles, realidad aumentada y música, a la vez. De esa lista, seleccionamos los más relevantes para nuestro proyecto.

Scrapple

Este sistema, desarrollado por Golan Levin en la School of Art de la Carnegie Mellon University en el 2005, es una instalación que consta de una superficie similar a la de un pizarrón de marcador, una cámara, una software corriendo sobre Windows y un proyector.

La interfaz proyecta algo similar a un espectrograma, sobre el cual se colocan (o dibujan) objetos que son “reproducidos” secuencialmente una y otra vez. La posición horizontal especifica el tiempo en el compás, mientras que la vertical define el tono del sonido, que se expande en un rango de 8 octavas. Un indicador se proyecta sobre el espectrograma indicando la posición actual de la reproducción en el loop, mientras que una especie de brillo se puede ver alrededor de los objetos reconocidos.

La superficie con los objetos y la proyección

La cámara y el proyector no están colocadas en ninguna posición particular: la imagen captada es transformada de forma que la superficie se vea desde arriba y en proyección ortogonal. Esta imagen es sobre la cual trabaja el algoritmo de reconocimiento de objetos. Para proyectar la interfaz sobre la superficie, se hace una transformación inversa.

Tal vez el aporte más importante que pueda hacer a YARMI, es del mecanismo utilizado para evitar la retroalimentación de la proyección hacia el sistema de visión de computadora (que puede llegar a ser un problema en este modo de funcionamiento). Éste consiste iluminar la superficie y los objetos con una fuente de luz infraroja, y utilizar una cámara con un filtro IR optimizado para dejar pasar luz de frecuencias algo mayores a 750 nanómetros. De esta forma se puede lograr, aprovechando el hecho de que los proyectores emiten muy poca luz en esa porción del espectro, que el sistema de visión de la máquina y la percepción visual del usuario no se vean afectados mutuamente.

El paper puede verse acá.

Un video:

Music Table

Desarrollado en el 2003 en el ATR Media Information Science Laboratories, en Japón, este secuenciador de música es más “portable” que el anterior. Consiste también en una cámara y un conjunto de fichas (fiducials en este caso) que se colocan sobre una superficie plana, a diferencia que en este caso la imagen se genera en un monitor, sobre el feed de video original.

Fue desarrollado utilizando la ARToolkit (uno de los frameworks de visión para realidad aumentada) y PD (un lenguaje de programación gráfica orientado a la creación musical interactiva), dos herramientas que seguramente nos serán de utilidad.

El sistema Music TableEl concepto más interesante viene por el lado del diseño de la interacción. Una ficha especial llamada copy card, puede ser usada para asignar el patrón musical creado y actualmente en reproducción a una phrase card. De esta manera, las fichas que lo conformaban y el espacio que ocupaba quedan libres para crear nuevos patrones, mientras la phrase card donde quedó salvado puede usarse en cualquier momento para reproducir el patrón original. Además, una phrase-edit card puede ser utilizada  para modificar distintos parámetros de las notas que componen el patrón almacenado.

Link al paper.