mapping.imatgedart

Aunque parecía que finalmente no iba a haber ningún acto de clausura más o menos oficial de nuestro periodo de residencias, a propuesta de Joana decidimos hacer algo informal y con pretensiones de no tenerlas 😉 . La clave de la cuestión era que de entrada la cerveza acompañara el evento y que nosotros, como ponentes, no preparáramos nada muy denso ni lucido, sino solamente presentar aquello que ya tuviéramos y resultara cómodo y fácil de mostrar. Como suele pasar en esos casos, la cosa fue formalizándose a medida que todo el mundo iba tomando conciencia de que eso acontecería.

Aunque el speech sobre nuestros proyectos fuera con la luz apagada y nos aplaudieran, de todas formas el evento mantuvo el carácter de reunión de amigos, y repetimos la arepada que Javi y Dani habían tenido a bien de ofrecer uno o dos días antes.

Para presentar mis resultados, yo monté la instalación base de el Màpping de veritat, sólo que en ese caso la proyección que se lanzaba dependía precisamente del patch que acompaña ese post, y que permitía mezclar los varios clips (que antes proyectaba de forma secuencial, uno detrás de otro) utilizando los botones del MultiTouchXY de Control como sliders de esa mezcla.

En el OSCroute se filtran todos los pares de coordenadas, X e Y, aunque para ese patch y como en otras ocasiones sólo usé X, para simplificar. Fíjate además que los botones 1 a 4 sirven propiamente para el ajuste de la mezcla, mientras que 5 lo que hace es ajustar la velocidad de fotogramas del quinto clip. Eso no acaba de funcionar del todo bien puesto que a velocidades lentas la reproducción parece atrancarse y no se ve fluida.

Aquí aún no había aprendido a integrar los patches de Extended View con otros patches personalizados (lo explicaré pronto en otro post), por lo que tuve que hacer el ajuste entre proyección y poster usando solamente los ajustes del proyector. Algo que en ese caso fue muy cómodo, casi un lujo, gracias a las excelentes prestaciones y calidad de imagen del proyector que me prestaron en Medialab-Prado para ello, un Mitsubishi HC6800.

Info complementaria:

• Igual que pasa en los otros patches donde hay referencias a elementos externos, es particularmente importante que estas se preserven, o que se actualicen oportunamente.

El tema de mandar mensajes por OSC era otro de los caramelillos de trabajar en Puredata. Básicamente porque este es el método que usan algunos controladores MIDI (en particular los virtuales, en soporte smartphone o de tableta) para mandar los mensajes de los varios ajustes que como usuarios vamos haciendo.

Hace un tiempo usé FingerPlay e hice alguna prueba exitosa con algun patch de PD que había descargado. Sin embargo volví a probarlo durante mi residencia y parecía que los mensajes OSC no se enviaban correctamente; ya hago el aviso a navegantes de que el programa parece bastante abandonado.

Así que busqué otras aplicaciones parecidas y me encontré con Control, que funcionaba correctamente; además tiene buena pinta porque parece que con un poco de Javascript uno puede hacerse sus propias interfaces.

El patch de ese artículo tiene partes que funcionan y otras que no. Si no no sería experimental, claro está 😉 . Está pensado principalmente para ser testeado con la interfaz MultiTouchXY que ya viene con Control. Con esa interfaz se mandan desde el teléfono o la tablet pares de coordenadas. En el caso del unpack de la izquierda se muestran con independencia del “botón” que estemos usando, mientras que a la derecha se filtran usando OSCroute. Otro OSCroute permite filtrar los datos entre los que vienen de la interfaz MultiTouchXY y los que vienen de la interfaz del accelerómetro, también incluida por defecto.

Esa posibilidad de control remoto por OSC son los cimientos de lo que hice después y un poco como conclusión de mi estancia: un mapping de pequeño formato en el que usamos la interfaz MultiTouchXY de Control para ajustar la mezcla de vídeo entre varios clips. Lo veremos en el siguiente post.

Servando Barreiro es un artista sonoro/visual que estuvo participando en el periodo anterior de residencias de Medialab-Prado antes de que lo hiciéramos Vanessa, Joana y yo mismo. Trabaja principalmente con Puredata y podéis ver una muestra de lo que hace en http://servando.teks.no Aunque del taller que yo impartía le interesaba especialmente la pequeña introducción a Blender que tenía prevista, participó en todas las sesiones y sus aportaciones y la pequeña introducción a Puredata que impartió fueron muy enriquecedoras.

Durante aquella sesión hice ese patch que ilustro aquí; aunque la mayoría de cosas que comentó ya las había visto en una u otra parte de la documentación o los ejemplos, también dio una buena cantidad de pequeñas perlas, de las que no suelen aparecer en ningún tutorial y que sólo se aprenden como consejo aparentemente casual de alguien que sabe mucho sobre un tema. Como por ejemplo el hecho de poder operar en Puredata en modo de control en Puredata sin salir del modo de edición, pulsando la tecla Control (o manzanita en Apple, creo).

La detección de tono, pitch en inglés, es lo que nos permite diseñar una interacción de forma que pasen cosas diferentes en función del tono, la nota en lenguaje común, que capta el micrófono u otro dispositivo de entrada de audio.

El patch que veis aquí ilustrado está sino del todo casi completamente copiado de la página de tutoriales de PD de Matías Romero Costas, a la que os recomiendo más de un vistazo.

Y eso es todo para hoy 😉

En la entrada anterior expuse un patch relativamente simple en el que posicionábamos una imagen encima de otra usando los datos que se extraían del tracking de una fuente de vídeo, y expliqué que la intención original era hacer una multiplicación de color entre las dos. Como soy bastante testarudo, aunque aquello no me funcionara seguí buscando otra forma de conseguir lo mismo.

Ese patch no deja de ser un más de lo mismo de otros que ya hemos visto en relación a como se enfoca el flujo de datos, pero puede observarse funcionando correctamente la multiplicación de color entre una fuente de imagen y otra de vídeo (la multiplicación entre dos fuentes de vídeo o de imagen también funcionaría sin problema, en principio). Se trata de un vídeo de un degradado que se desplaza horizontalmente. Dirigiendo los datos de tracking al frame de reproducción del vídeo podemos hacer que el degradado se sitúe en un sitio u otro, también.

Lo que quería conseguir era un efecto parecido a la imagen del cuadrado con el degradado esférico mediante la multiplicación de color con otro vídeo en el que el degradado se desplaza verticalmente. Algo difícil de explicar en palabras, pero confío que si experimentas y trasteas con lo que hay en la documentación descargable comprendas a lo que me refiero.

Aquí y allí hay otros añadidos y pruebas, como el hecho de usar un objeto [line] para tratar de suavizar o controlar aún más los datos que [pix_blob] expulsa. Tal como advertí, sin ninguna garantía de que sea una buena solución.

El principio de ese patch es el mismo que el anterior puesto que también estamos usando [pix_movement] para determinar la diferencia cromática entre frames y [pix_blob] para evaluarla numéricamente y así obtener unas coordenadas.

La formalización y efecto final de ese patch son los que son porque vienen de un intento fallido de usar [pix_multiply] con dos fuentes de vídeo diferentes y de tamaño también diferente (cosa que provoca un error y es por esa razón que existen los [pix_resize]), de forma que el resultado visual fuera la multiplicación cromática de la imagen de la webcam por los valores del degradado esférico de grises del cuadrado correspondiente a la imagen degradat.jpg.

En ese patch, por lo tanto, el efecto es simplemente que esa imagen del cuadrado con el degradado esférico se va situando en la posición de las coordenadas que se evaluan en el proceso de tracking de los movimientos del vídeo de la webcam.

A destacar solamente el hecho de que entre los receive [r x] y [r y] y los inlets de [translateXYZ] hacemos unas operaciones que nos permiten transformar el rango original de las coordenadas calculadas (de 0 a 1) al espacio de coordenadas propio de la ventana de GEM, que mide 5.33 en X y 4 en Y.

Entre las razones que desde hace mucho tiempo me motivaban a aprender Puredata están las posibilidades de tracking de movimiento que había ido leyendo por ahí que existían. Para ser exactos, desde que en 2010 experimenté con Animata y supe de las posibilidades de conectar ese software con Puredata a través de OSC para controlar títeres digitales. En aquel momento, sin embargo, no pasé de experimentar con patches elaborados por otros y usando sliders en lugar de tracking para controlar las coordenadas.

Por si es necesario aclarar el significado de tracking -aunque hay que tener en cuenta que es un término algo polisémico-, en el contexto al que ahora me refiero se trata de un análisis informático de una imagen en movimiento, con el fin de detectar cambios de posición de los objetos dentro de esta o incluso, a veces, el movimiento de la cámara que la captura.

En este caso usamos un tipo de tracking muy básico y algo rudimentario, pero que es perfectamente suficiente para testear la interactividad que ese tipo de aplicaciones nos pueden brindar. Como puedes suponer, encontrarás más información sobre eso en la página de Puredata de los FLOSS manuals.

Este patch consta de cuatro bloques de elementos interconectados. Uno de ellos es el que genera la ventana de GEM, ya lo hemos visto otras veces. Otro es el que contiene la cadena de render, que se inicia con [gemhead 0]. Ahí se carga una animación sencilla con un cubo que va de un lado para el otro.

El bloque de más a la derecha, que se inicia con [gemhead 2] es donde se procesa el tracking. A través del objeto [pix_video] se recibe la información visual de la webcam u otro dispositivo de captura de video. El objeto [pix_movement] es el que hace el tracking, usando un sistema que consiste en evaluar el frame del momento presente comparándolo con otro anterior en el tiempo. Por su inlet derecho podemos especificar un umbral en función del cual la detección será más fina o más basta. La información visual consistente en la diferencia cromática entre los dos frames se expulsa por el inlet y es [pix_blob] quien la convierte en coordenadas X e Y, que expulsa por su segundo y tercer inlet, respectivamente, junto a un valor de tamaño de la mancha (el blob) que se expulsa por el cuarto.

El bloque que se inicia con un [r x] (que podría escribirse también [receive x]) recibe la coordenada X que llega desde [pix_blob] a [s x]. En ese caso no usamos Y. El propósito de todos esos objetos es convertir esa información de coordenadas en un valor numérico de unas características y rango oportunos para lo que queramos usarla. En http://www.packtpub.com/books/content/motion-detection podéis ver contenido de muestra gratuito de dónde se han sacado algunas soluciones aplicadas aquí. En concreto el uso de un objeto [trigger f f b] y un float asociado que nos permiten determinar la dirección del movimiento, según el signo (positivo o negativo) del valor resultante. Ese valor lo multiplicamos y sumamos para que pueda gobernar el frame que se muestra de la película del cubo que tenemos cargada en [pix_film]. Ahora el movimiento de nuestro brazo o nuestra cabeza delante de la webcam puede hacer avanzar o retroceder la reproducción de ese clip de vídeo.

Después de superar el reto del reloj, me consideré preparado para empezar a experimentar y trastear propiamente con los objetos de GEM con más o menos garantías de que ya tenía aprendido lo básico de Puredata, y con posibles aplicaciones de todo ello al contexto del mapping.

El ejercicio de la mixer de video también está en los FLOSS manuals de Puredata. Aquí posteo mi versión, que en realidad no trabaja sobre vídeo sinó sobre una imagen fija, pero la idea y el procedimiento es el mismo.

Los dos objetos clave en ese patch son el [pix_alpha] i el [colorRGB], que nos permiten modificar la transparencia y los componentes de color, respectivamente, a través de varios sliders que expulsan valores entre 0 y 1. De forma complementaria, al final de la cadena de render también tenemos sliders que nos permiten alterar en X e Y la escala del rectángulo sobre el que se texturiza la imagen.

Recuerdo que, cuando iba al colegio, en la asignatura de informática hicimos un ejercicio en LOGO que consistía en programar un reloj. Más de veinte años más tarde, este verano en Medialab-Prado, pensé que este era un ejercicio interesante luego de familiarizarme con lo más elemental del lenguaje de Puredata. Porque por un lado es una meta clara, todo el mundo sabe cómo funciona un reloj. Pero por otro, el cómo las agujas se mueven las unas en relación con las otras entraña algunas dificultades que nos obligan a poner en práctica una gran diversidad de cosas aprendidas.

Todo el patch empieza con un [loadbang] que lanza en el momento de cargarse un impulso a varios objetos para iniciarlos. Una de las cosas que ese [loadbang] inicia es la creación de la ventana de GEM, que es donde se representará gráficamente el reloj. Recuerda que en esa entrada tienes el enlace para descargar el paquete que incluye este patch junto a otros que iremos viendo en futuros posts.

Es importante diferenciar las partes en el reloj que hacen el recuento de las fracciones de tiempo, propiamente, de aquellas que simplemente sirven para representar esas fracciones. Resolver lo primero antes de entrar en lo segundo nos evitará muchos quebraderos de cabeza. Usé los elementos de tipo number y los objetos [print] para testear precisamente eso.

Siendo el reloj una herramienta para medir o representar el tiempo, la parte esencial de él es precisamente la que genera aquella que consideremos su unidad mínima. En Puredata el tiempo se suele especificar en milisegundos, y el objeto que genera un impulso cada un determinado número de ellos es [metro]. Es un metrónomo, vaya. Puesto que ahora se trata de hacer un reloj más o menos convencional, trabajaremos en segundos. [metro 1000] generaría un impulso cada mil milisegundos, es decir un segundo. Pero ello haría muy lento comprobar si el reloj funciona correctamente. Por ello usamos un tiempo veinte veces más pequeño, cada 50 milisegundos, que nos da un balance cómodo entre rapidez y posibilidad de observar lo que ocurre a nivel numérico y gráfico. Si acaso después nos interesa que el reloj funcione de manera convencional, ya cambiaríamos ese valor de vuelta a 1000.

Los impulsos que lanza metro se envían a [float] y a su bucle asociado que añade +1 por cada uno de ellos, y eso es el contador de segundos. Una vez tenemos los segundos vemos que ese valor se distribuye en tres columnas según si queremos representar segundos, minutos u horas. Los minutos son el resultado de dividir los segundos entre 60. Los minutos divididos a su vez entre 60 dan como resultado las horas. En la esfera del reloj caben 12 horas, por lo que en algún momento tenemos que usar esa división también para poder hacer la representación gráfica.

Al final esos pares de coordenadas van a parar a sendos objetos [polygon] para cada manecilla. Esos polígonos de hecho son líneas, están definidos por 2 puntos solamente; una de sus coordenadas es 0,0,0 (también está la coordenada Z) mientras que la otra viene dada por los valores que el patch va enviando cada n milisegundos, según lo que tengamos en el objeto [metro].

Otras cosas a destacar o comentar:

• Verás que hay algunas sumas y restas de 90 grados y alguna multiplicación por valores negativos. El motivo es inicializar las rotaciones de las manecillas a la hora 12, y hacer que giren en el sentido correcto.
• Uso cálculos de seno y coseno para sacar las coordenadas x e y correspondientes a uno de los extremos de cada manecilla.