sistemas_interactivos en el arte

Vista previa del material en texto

Sistemas 
interactivos en el arte
Emiliano Causa, Diego Alberti
Índice Introducción Íconos
Unidad 1 Unidad 2 Unidad 3 Unidad 4
 
2
Causa, Emiliano
Sistemas interactivos en el arte / Emiliano Causa y Diego Javier Alberti. - 1a ed. - 
Bernal: Universidad Virtual de Quilmes, 2014. 
E-Book.
ISBN 978-987-3706-08-0 
1. Arte. I. Alberti, Diego Javier II. Título
CDD 708
Diseño instruccional y procesamiento didáctico: Bruno De Angelis 
Diseño, diagramación y desarrollo web: Alejandro Jobad
Programación: Marisol Martín
Primera edición: mayo de 2014
ISBN: 978-987-3706-08-0
© Universidad Virtual de Quilmes, 2014
Roque Sáenz Peña 352, (B1876BXD) Bernal, Buenos Aires
Teléfono: (5411) 4365 7100 http://www.virtual.unq.edu.ar
La Universidad Virtual de Quilmes de la Universidad Nacional de Quilmes se reserva la facultad de disponer de esta 
obra, publicarla, traducirla, adaptarla o autorizar su traducción y reproducción en cualquier forma, total o parcial-
mente, por medios electrónicos o mecánicos, incluyendo fotocopias, grabación magnetofónica y cualquier sistema 
de almacenamiento de información. Por consiguiente, nadie tiene facultad de ejercitar los derechos precitados sin 
permiso escrito del editor.
Queda hecho el depósito que establece la ley 11723
3
Íconos
Leer con atención 
Son afirmaciones, conceptos o definiciones 
destacadas y sustanciales que aportan cla-
ves para la comprensión del tema que se 
desarrolla. 
Para reflexionar
Propone un diálogo con el material a tra-
vés de preguntas, planteamiento de pro-
blemas, confrontaciones del tema con la 
realidad, ejemplos o cuestionamientos que 
alienten la autorreflexión.
Texto aparte
Contiene citas de autor, pasajes que contex-
tualicen el desarrollo temático, estudio de 
casos, notas periodísticas, comentarios para 
formular aclaraciones o profundizaciones.
Pastilla
Incorpora informaciones breves, comple-
mentarias o aclaratorias de algún término o 
frase del texto principal. El subrayado indica 
los términos a propósito de los cuales se in-
cluye esa información asociada en el margen.
Cita
Se diferencia de la palabra del autor de la 
Carpeta a través de la inserción de comi-
llas, para indicar claramente que se trata de 
otra voz que ingresa al texto.
Ejemplo
Se utiliza para ilustrar una definición o una 
afirmación del texto principal, con el objetivo 
de que se puedan fijar mejor los conceptos.
Código
Incorpora al material un determminado 
lenguaje de programación.
Para ampliar
Extiende la explicación a distintos casos o 
textos como podrían ser los periodísticos o 
de otras fuentes.
Actividades
Son ejercicios, investigaciones, encuestas, 
elaboración de cuadros, gráficos, resolu-
ción de guías de estudio, etcétera.
Audio
Fragmentos de discursos, entrevistas, re-
gistro oral del profesor explicando algún 
tema, etcétera.
Audiovisual
Videos, documentales, conferencias, frag-
mentos de películas, entrevistas, grabacio-
nes, etcétera.
Recurso web
Links a sitios o páginas web que resulten 
una referencia dentro del campo discipli-
nario.
Lectura obligatoria
Textos completos, capítulos de libros, artí-
culos y papers que se encuentran digitali-
zados en el aula virtual.
Lectura recomendada
Bibliografía que no se considera obligato-
ria y a la que se puede recurrir para ampliar 
o profundizar algún tema.
Línea de tiempo
Se utiliza para comprender visualmente 
una sucesión cronológica de hechos.
4
5
Índice
Los autores 7
Introducción 8
Objetivos del curso 8
Unidad 1 
Sistemas interactivos en el arte
1.1. Introducción 9
1.2. Arquitectura de un sistema interactivo 10
 1.2.1. Instalaciones interactivas 12
 1.2.2. Hardware y software de los sistemas 
 interactivos en el arte: lo físico y lo virtual 14
 1.2.3. Los campos de acción: sensado, 
 reproducción, generación y control 15
 1.2.4. Lenguajes de programación y herramientas 
 de control 16
 1.2.5. Taxonomía del software de los sistemas
 interactivos en el arte 17
 1.2.6. Sistemas operativos 25
 1.2.7. Sistemas ópticos de sensado de posición 
 y silueta 25
 1.2.8. Protocolos de comunicación 31 
 1.2.9. Hardware de los sistemas interactivos: 
 sistemas de control y sensado físico 33
Unidad 2 
Imagen y sonido en tiempo real
2.1. Introducción 35
2.2. La computadora personal como herramienta 35
2.3. Herramientas de software	 38
	 2.3.1. Pure Data (PD) 38
 2.3.2. Processing 40
2.4. Ejemplo de aplicación 41
2.5. Generación de imagen a partir de Processing y 
 datos por osc 53
Unidad 3 
Visión por computadora
3.1. Introducción 58
3.2. Captura óptica de movimiento 58
 3.2.1. Captura por substracción de movimiento 58
3.3. Captura devideo en Processing 61
3.4. La substracción de video 62
3.5. Cómo se programa con la captura de movimiento 64
 3.5.1. Los métodos principales 67
 3.5.2. Calibrar el umbral 68
 3.5.3. Monitoreo del resultado 68
 3.5.4. A la búsqueda del movimiento 69
3.6. Revisión de la clase PMoCap 71
3.7. Aplicación de la captura de movimiento 75
Unidad 4 
Detección de contenido e interfaces tangibles
4.1. Detección de Blobs 81
 4.1.1. La librería BlobDetection 83
 4.1.2. Un ejemplo con detección de Blobs 84
4.2. Sistema de detección de patrones para 
 la implementación de una mesa reactiva 95
 4.2.1. El protocolo TUIO 98
 4.2.2. El funcionamiento del ejemplo 102
4.3. Breve comentario final 111
Referencias bibliográfícas 113
6
7
Los autores
Emiliano	Causa
Nació en La Plata (Argentina) en 1970. Artista multimedia e Ingeniero en Sistemas de Infor-
mación (Universidad Tecnológica Nacional). Integrante fundador del grupo Proyecto Biopus 
(www.biopus.com.ar). Fue Coordinador del MediaLab del Centro Cultural de España en Bue-
nos Aires. Ha sido Coordinador de la Dirección de Investigación y Posgrado en el Área de Artes 
Multimediales del IUNA. Es profesor de Arte Multimedia e Informática Aplicada en la Licen-
ciatura de Artes Multimediales del IUNA. Profesor de Tecnología Multimedia de la carrera de 
Diseño Mutimedial de la Facultad de Bellas Artes de la Universidad Nacional de La Plata. 
Dirige el Laboratorio de Experimentación EmmeLab de la Facultad de Bellas Artes UNLP. Es profesor de Sistemas Diná-
micos II de la Maestría en Artes Electrónicas de la UNTREF. Dicta el Taller de Investigación y Realización de Objetos II en 
la Especialización de Teatro de Objetos del Área de Artes Dramáticas del IUNA. Trabaja en investigaciones relaciona-
das con Bioarte, Realidad Aumentada y Arte Generativo. Fue docente de Informática en las carreras de Composición 
Musical y Cine en la UNLP y de Inteligencia Artificial en Ingeniería de Sistemas en la UTN. 
Actualmente trabaja en investigación y dicta cursos de posgrado relacionados al arte interactivo y nuevas interfaces 
(sensores y control de video y sonido en tiempo real). Se dedica al arte interactivo, al arte generativo, a la construcción 
de instalaciones interactivas y a la aplicación de la informática al arte en general.
Diego	Alberti
Estudió Diseño de Imagen y Sonido y Diseño Gráfico (FADU, UBA). Realizó diversos cursos 
de posgrado y talleres relacionados con arte y nuevas tecnologías. Actualmente produce 
música electrónica, videos, software y piezas de arte digital.
Expuso su obra en Museo Macro de Rosario, Museo Municipal de Bellas Artes Juan B. Castag-
nino de Rosario, Museo de Arte Contemporáneo de Bahía Blanca, Centro Cultural Recoleta, 
Centro Cultural San Martín, Centro Cultural de España en Buenos Aires, Museo Municipal de 
Arte Ángel María de Rosa de Junín, Espacio Fundación Telefónica de Buenos Aires, Museo de 
Arte Moderno de Mendoza, medialabPrado Madrid y FILE Festival de San Pablo.
Es docente de la materia Informática Aplicada 2 Artes Multimediales en el Instituto Universitario Nacional de Arte y de 
la materia Dibujo y Maqueta Cátedra Vitullo de la carrera de Diseño de Imagen y Sonido en Facultad de Arquitectura 
Diseño y Urbanismo de la Universidad de Buenos Aires.
Dicta cursos sobre tecnología y nuevos medios en diversas instituciones del país: MBA/MAC deBahía Blanca, Univer-
sidad Nacional de Noreste, Centro Cultural de España en Buenos Aires, Universidad de Palermo, Centro Cultural de 
España Chile, Centro Cultural Balmaceda Arte Joven, Valparaíso, Chile.
Trabaja y reside en Buenos Aires, desarrolla diferentes proyectos artísticos relacionados con electrónica, nuevas tec-
nologías y software. Colabora con artistas como Carlos Trilnick, Gabriel Valansi, Marina de Caro, Juan Rey, Mariano 
Giraud, Ernesto Romeo, Jorge Haro y otros.
 
8
Introducción
En este mateiral desarrollaremos los aspectos fundacionales de lo que consideramos elemental a cualquier obra de 
arte interactiva que utilice tecnología. Nos referimos esencialmente al uso de software para lograr aplicaciones de 
audio y sonido que permitan la generación en tiempo real de espacios sinestésicos donde imagen y sonido se com-
plementen de manera homogénea. 
Utilizaremos los dispositivos más inmediatos con los que contamos en una computadora personal para realizar acti-
vidades donde la imagen y el sonido interactúen de forma dinámica.
Recurriremos a cámaras de video para detectar presencia o actividad dentro de una escena y con ella producir sonido 
y como contraparte veremos cómo analizar audio proveniente de un micrófono para generar o modificar una imagen.
Consideramos que este acercamiento por demás elemental esconde un alto nivel de complejidad producto del avan-
ce constante de la tecnología puesta en juego y de la enorme cantidad de variables que aparecen involucradas en el 
desarrollo de este tipo de aplicaciones; principalmente en lo relacionado a lo azaroso del mundo real y el comporta-
miento imprevisible de los individuos interactuantes. En ese sentido es que invitamos a los estudiantes a profundizar 
cada uno de los temas abordados a partir de los conceptos fundamentales que aquí se presentan. 
Esperamos que esta colección de recursos sirva como disparador para poder luego ahondar en la complejidad que el 
tópico propone.
Los foros y la documentación relacionada con las aplicaciones utilizadas son nuestras fuentes de información, es por 
eso que recomendamos a los estudiantes consultar sistemáticamente toda la información referida a los problemas 
concretos en la web ya que es allí donde la información permanece actualizada.
Esperamos que disfruten la lectura de este material y que consigan completar con éxito las consignas y ejercicios que 
aquí se presentan.
Objetivos del curso 
• Conocer las principales herramientas disponibles para producir obras interactivas.
• Reconocer los tipos y variantes de herramientas de manera de poder elegir con libertad cuál o cuáles son las que se 
adaptan de modo más preciso a los conceptos que pretenda trabajar en su obra.
• Conocer los principios fundamentales sobre los que funcionan dichas herramientas para poder entonces explotar 
sus capacidades al máximo como así también modificarlas según su necesidad.
• Crear sus propias herramientas a partir de otras existentes o desde cero.
• Conocer los algoritmos y técnicas mayormente empleadas en este tipo de dispositivos y utilizarlas, extenderlas o 
mejorarlas según su conveniencia. 
• Realizar una instalación audiovisual interactiva completa, susceptible de ser expuesta en un ámbito profesional.
La cibernética es una ciencia introducida en la década de 1940 por Norbert Wiener. Trata del estudio de los 
sistemas autoregulados. La idea de interactividad está íntimamente relacionada con estos conceptos aun-
que de manera superadora. En general, lo que se espera de una obra interactiva es que de alguna manera 
“dialogue” con el espectador y no sea solo una acción reactiva la que deviene frente al estímulo del público.
Este material no intenta ser una definición sobre el arte interactivo en términos conceptuales, sino más 
bien una descripción general de nuestro objeto de estudio, abordado desde un punto de vista tecnológico.
En el siguiente enlace encontra-
mos información sobre Norbert 
Wiener: <http://www.uwiener.edu.
pe/nosotros-norbertwiener.aspx>
9
1. Sistemas interactivos en el arte 
Objetivos
• Incorporar conocimientos introductorios sobre el campo de la multimedia aplicada fundamentalmente a los siste-
mas interactivos en tiempo real.
• Reflexionar sobre las cuestiones tecnológicas elementales que hacen a la particularidad de esta disciplina.
• Conocer las relaciones intrínsecas existentes entre software y hardware.
• Proyectar una obra tecnológica teniendo en cuenta los aspectos fundamentales generalmente desarrollados en 
este campo.
1.1. Introducción
En esta unidad nos ubicaremos en el campo de la multimedia aplicada y focalizaremos en los sistemas interactivos en 
tiempo real. Entendemos por “tiempo real” toda aquella actividad en donde el resultado del estímulo generado por 
el espectador o interactor aparece reflejado en una consecuencia sinestésica más o menos instantánea. Llamamos 
sinestésico a todo aquel fenómeno donde se ven involucrados diferentes sentidos a la vez.
 
Cuando hablamos de sistemas interactivos aplicados al 
arte, nos referimos a experiencias en las que el públi-
co se enfrenta con un objeto, instalación, aplicación o 
performance, con la que puede interactuar generando, 
influenciando o controlando el desarrollo de estos. 
Por decirlo de otra forma, un sistema interactivo es capaz de “percibir” al público o ciertas acciones o particularidades 
de este y generar una respuesta a través de dispositivos y medios de representación. Su característica central se vin-
cula con la capacidad de lograr inmediatez entre las acciones del público y la respuesta generada; lo que en nuestro 
campo se llama “tiempo-real”. La generación de esta respuesta a través de medios de representación (como el sonido 
y la imagen) en tiempo real, solo es posible (salvo raras excepciones) por medio del procesamiento de la información 
mediante computadoras y por ende, las técnicas y herramientas para la producción de sistemas interactivos está 
fuertemente ligada a la informática y a la electrónica.
Es la ley de Moore según la cual 
“aproximadamente cada 18 me-
ses se duplica el número de tran-
sistores en los circuitos integra-
dos”, es decir, que la tecnología 
crece a un paso exponencial. 
Ley de Moore: <http://www.com-
puterhistory.org/semiconductor/
timeline/1965-Moore.html>
Jim Campbell, artista estadouni-
dense, pionero en el uso artístico 
de la tecnología lumínica de los 
LED y considerado entre los más 
vanguardistas del Siglo XXI. Li-
cenciado en ingeniería eléctrica y 
matemáticas en el Massachusetts 
Institute of Technology (MIT) en 
1978, Campbell buscó en el arte 
un equilibrio entre su labor en 
el reconocido centro de inves-
tigación tecnológica de EE.UU. 
y su vida diaria. “Primero fueron 
películas. A los 10 años de estar 
trabajando en el MIT empecé a 
integrar mi lado artístico con la 
ingeniería. Mi interés siempre 
está en la imagen y en cómo utili-
zar la tecnología para presentarla 
de manera que se vea distinta”.
Fuente: Muestra Jim Campbell en 
el Espacio Fundación Telefónica: 
20 años de arte electrónico. Dispo-
nible en: <http://planetatelefoni-
ca.com.ar/fundacion/2011/07/21/
jim-campbell-en-el-eft20-anos-
de-arte-electronico/>
10
El campo de estudio en el que pretendemos involucrar-
nos es en extremo extenso por la diversidad de recur-
sos y herramientas con las que contamos para producir 
nuestras obras y por la profundidad necesaria con la 
cual debemos abordar el aprendizaje de estos temas 
para lograr superar las barreras técnicas que estos dis-
positivos o herramientas nos presentan. Si bien esto no 
debiera ser motivo de conflicto sucede que, además 
de ser un campo extenso, este se expande de manera 
exponencial conforme avanza el desarrollo tecnológi-
co tanto de las aplicaciones como de los dispositivos 
informáticos. Esto a su vez trae aparejada la aparición 
repentina de nuevos espacios de acción. 
Es por esto que nos vemos obligados a tratar de lograr un enfoque metodológico y además conceptual respectode las disciplinas asociadas al uso de computadoras en el arte y los multimedios. Esta unidad en particular aparece 
como una introducción a este cambiante mundo de acción en el cual los conocimientos sobre los dispositivos y he-
rramientas que lograremos aprender hoy, seguramente serán obsoletos el día de mañana. De ahí la importancia de 
centrarnos en los conceptos fundamentales de esta disciplina.
1.2. Arquitectura de un sistema interactivo
Jim Campbell, en su Formula	for	computer	art, plantea 
un esquema acabado que representa casi cualquier 
configuración de una obra interactiva mediada por un 
dispositivo informático. Lo que plantea es un esquema 
claramente dividido en tres secciones: input (entrada), 
program/memory (un programa y la memoria en el dis-
positivo), output (salida). En términos prácticos se refie-
re a las posibilidades intrínsecas de estos dispositivos 
(las computadoras) y las posibilidades que existen de 
que puedan interactuar con el mundo real.
Según Campbell, cualquier obra mediada con compu-
tadoras presenta un dispositivo de entrada que es el 
encargado de convertir por medio de diversos sensores 
y conversores, estímulos físicos o perceptibles en térmi-
nos naturales o culturales en datos digitales, los cuales 
pueden ser manipulados por sistemas informáticos.
En la entrada del esquema siguiente (Imagen 1.1.)se 
encuentran como ejemplos de variables del entorno 
el ruido, palabras habladas, viento, temperatura, terre-
motos, respiración, color, intensidad lumínica, etcétera. 
Todos estos estímulos pueden ser “percibidos” por la 
computadora a través de conversores y sensores que 
son específicos para cada magnitud.
Es importante aclarar que todos los sensores con los que trabajamos convierten de alguna u otra forma 
una magnitud o parámetro del mundo físico en una magnitud eléctrica. Estos sensores se encuentran ge-
neralmente conectados a una interfaz digitalizadora, es decir, un dispositivo preparado para comunicar 
esas señales eléctricas producidas por el sensor en el “lenguaje” que la computadora puede comprender. 
Esto es básicamente un conversor “analógico-digital”. Nuestro estudio estará fuertemente inclinado a 
los sistemas de captura de sonido y ópticos ya que son los dispositivos más inmediatos y que mayores 
prestaciones ofrecen al intentar capturar información en tiempo real de una escena o un dispositivo de 
interfaz tangible.
11
Imagen 1.1. Formula for computer art
Fuente: imagen obtenida de <http://www.jimcampbell.tv/portfolio/miscellaneous_references/>
 
Formula	for	compurter	art,	en:
<http://jimcampbell.tv/portfolio/miscellaneous_references/>
Se	 puede	 ver	 el	 mismo	 esquema	 en	 Campbell,	 (1996),	 Ilusiones	 del	
diálogo:	control	y	elección	en	el	arte	interactivo.	
Como material central en su trabajo, Jim Campbell utiliza la idea de memoria, por ese motivo hace hincapié dentro de 
su esquema en el ítem Memory	(invisible): memoria invisible.
La memoria es un componente fundamental de la computadora ya que permite que las operaciones puedan ser 
realizadas. La otra parte que Campbell propone como relevante son los algoritmos. En nuestro caso, esos algoritmos 
y esa memoria está mediatizada por softwares disponibles tanto como producto comercial o experimental o aquellos 
que nosotros mismos podemos construir para desarrollar nuestras propias experiencias. 
Por último, el esquema señala un controlador de salida: es cualquier dispositivo capaz de recibir instrucciones desde 
un ordenador y a su vez traducir esa información en señales que pueden controlar diversos artefactos electrónicos o 
resultados concretos esperados por tal o cual dispositivo. Campbell menciona “texto que se mueve”, “objetos moto-
rizados”, “generadores de viento”, etc. En general, nos limitaremos a artefactos capaces de producir sonido o imagen 
(proyectores, pantallas, sistemas de sonido, etcétera).
12
En resumen, en cualquier dispositivo tecnológico multimedial podemos encontrar tres partes claramente definidas: 
un subsistema de entrada de datos, un proceso ligado a operaciones informáticas (de automatización de datos) y un 
subsistema de salida que devuelve al medio el resultado del proceso sobre los elementos de entrada.
1.2.1. Instalaciones interactivas
Un ejemplo completo de aplicación donde se verifica esta hipótesis es el caso de la obra Residua de Fabián Nonino y 
Diego Alberti con coreografía de Maria Zegna, Valeria Cuesta y Rhea Volij.
Imagen 1.2. Residua, instalación interactiva. Centro Cultural Recoleta.
Fuente: cortesía del artista. 
En	el	siguiente	enlace	se	puede	acceder	a	la	obra	Residua
<http://olaconmuchospeces.com.ar/archives/100>
Texto Aparte
Residua es una instalación interactiva performática para personas con teléfonos 
celulares, cantante lírica y software. Fue estrenada en el Centro Cultural Recoleta 
en noviembre de 2008, en el marco del Festival Tecnoescena. La instalación prevé 
dos estados: un modo de instalación autónoma y otro de performance en vivo. 
Antes de ingresar a la sala, los espectadores son informados del funcionamiento: 
ingresan a un espacio construido con hojas de papel blanco que, en un principio, 
se conserva prístino. El público puede transitar por este espacio.
Una vez allí son invitados a enviar un mensaje de texto a un número predetermi-
nado. Los textos enviados al sistema aparecen proyectados en las paredes de la 
escenografía; a su vez, un sintetizador de voz los canta. En ese momento se inicia 
13
una búsqueda en internet al respecto de esos mensajes que devuelve fragmentos 
de oraciones extraídos de los resultados obtenidos. Para esa búsqueda se utilizan 
diversos buscadores como Yahoo y Google. Toda la información tanto de los textos 
ingresados, los números de los celulares participantes y las búsquedas devueltas 
son almacenados en una base de datos. Junto a los textos enviados por los espec-
tadores comienzan a aparecer todos los resultados obtenidos en las búsquedas. 
Comienza así el proceso de polución, degradación y contaminación del espacio. Un 
espacio que se escribe virtualmente ya que esos textos desaparecerán al terminar 
la función. El objetivo es que el ingreso de palabras en el sistema provoque un 
exceso de información tanto visual como sonoro creando así un entorno espectral, 
sucio pero a la vez poético y metafórico. El espacio se contamina por el progresivo 
aumento de información visual y auditiva, en una serie de acciones y respuestas 
encadenadas que inciden en el movimiento y desarrollo de la obra. Un software es-
pecialmente diseñado recompone esos textos y los conecta visualmente unos con 
otros a partir de algoritmos de reconocimiento de contexto y sistemas lingüísticos 
adaptados para tal propósito. La colección de oraciones evidencia juegos polisémi-
cos. Las conexiones entre los textos suponen un nuevo uso original del lenguaje. 
Las oraciones encontradas visualizadas en este espacio representan el uso banal de 
las palabras, que por sí solas, son carentes de emociones. Al escuchar una palabra, 
esta se carga de sentido, en función de la interpretación que ese otro hace de ella. 
El hecho de mostrar y develar todas las oraciones o pedazos de textos en que se en-
cuentra esa palabra enviada pone en evidencia ante el espectador mismo muchas 
de las dimensiones posibles en que puede ser comprendido ese vocablo.
Imagen 1.3. Esquema de sistema para tres pantallas
Fuente: elaboración propia
La imagen anterior (1.3.) es un esquema del sistema para tres pantallas: el software 
recibe como input mensajes, búsquedas que realiza en la web y un control de joys-
tick para manipular la visualización en tiempo real. Como salida tenemos el sistema 
de pantallas inmersivo y el sistema de sonido donde se reproduce la banda sonora 
con el agregado de los textos cantados y las sonificaciones de los eventos.
DAC: acrónimo de Digital	Analog	
Converter	o	Conversor digital ana-
lógico. Una explicación exhaus-
tiva de los diversos tipos de con-
vertidores puede encontrarse en 
estedocumento: <http://www.
asifunciona.com/electronica/af_
conv_ad/conv_ad_5.htm>
14
1.2.2. Hardware y software de los sistemas interactivos en el arte: lo físico y lo virtual
En los sistemas interactivos aplicados al arte, uno de los puntos centrales de su objeto de estudio se centra en la rela-
ción que se construye entre el público y la obra entendido desde este punto de vista: las particularidades existentes 
entre el cuerpo humano y el sistema interactivo. Cuando hablamos de comunicación entre el cuerpo y un sistema, 
aparece el campo de la “interfaz”. Gui Bonsiepe describe la interfaz de la siguiente forma:
En primer lugar existe un usuario o agente social, que desea efectivamente cumplir 
una acción. En segundo lugar se encuentra una tarea que él mismo quiere ejecutar 
[...] En tercer lugar existe un utensilio o un artefacto del que necesita el agente 
para llevar a término la acción [...] Y aquí aparece la cuestión de cómo se pueden 
conectar, hasta formar una unidad, a tres elementos tan heterogéneos: el cuerpo 
humano, el objetivo de una acción, un artefacto o una información en el ámbito de 
la acción comunicativa. La conexión entre estos tres campos se produce a través 
de una interfase. Se debe tener en cuenta que la interfase no es un objeto, sino un 
espacio en el que se articula la interacción entre el cuerpo humano, la herramienta 
(artefacto, entendido como objeto o como artefacto comunicativo) y objeto de la 
acción. [...] la interfase vuelve accesible el carácter instrumental de los objetos y el 
contenido comunicativo de la información. Transforma los objetos en productos; 
transforma la simple existencia física (Vorhandenheit) en el sentido de Heidegger, 
en disponibilidad (Zuhandenheit). (Bonsiepe, 1999: 17)
En el caso de los sistemas informáticos, esta interfaz puede dividirse en dos espacios, el de los dispositivos común-
mente considerados de entrada/salida (hardware) y el de las aplicaciones o programas que son mediadas a través de 
estos dispositivos (software). Se puede considerar que en términos “físicos” el público se enfrenta a un conjunto de 
dispositivos que generan representaciones, interfaz física, pero en términos “virtuales” las representaciones (produci-
das por estos dispositivos) constituyen una interfaz virtual.
Es común que en informática se contrapongan lo “físico” a lo “lógico”, entendiendo por “lógico” aquello que existe 
representado como dato y que no tiene una manifestación física, tangible. En este sentido, lo virtual se inscribe en 
el mundo de lo lógico. Estas distinciones puede parecer que no tienen importancia, a primera vista, pero en nuestra 
práctica trabajar del lado virtual o físico de la interfaz puede acarrear diferentes tipos de problemas.
El trabajo con entidades virtuales (lógicas) se relaciona con problemáticas del tipo algorítmicas en donde se debe 
decidir cuál es la mejor estrategia para procesar determinado tipo de información en pos de un resultado, es decir, 
problemas en el campo de la informática. El trabajo con entidades físicas, se vincula con problemas mecánicos, elec-
tromagnéticos y otros, del orden de la física y la ingeniería, y sus estrategias muchas veces deben apuntar a lograr 
limpiar el ruido intrínseco del mundo físico para poder extraer información de sus fenómenos. 
Para ejemplificar casos dentro de estos territorios, la 
generación de imágenes en tiempo real es un proble-
ma del orden virtual, ya que su problemática es casi es-
trictamente algorítmica. Realizar una detección de mo-
vimiento por medios ópticos se encuentra relacionado 
con ambos aspectos ya que, por un lado se debe obte-
ner información de un dispositivo de entrada (una cá-
mara de video), teniendo en cuenta el ruido propio del 
dispositivo y la iluminación, pero también es necesario 
realizar un arduo procesamiento de esa información. 
Por último, controlar un motor mediante una interfaz de conversión DAC puede, muchas veces, estar estrictamente 
ligada al campo de los problemas físicos: cálculos de corriente y potencia, estrés mecánico de los materiales, etcétera.
En este sentido es que aparecen 
disciplinas como la del VJ, que 
análogamente a la tradición del 
DJ, ejecuta su arte generalmente 
reproduciendo en sincronía con 
la música ediciones de material 
videográfico. Audiovisualizer.com 
es uno de los sitios más antiguos 
que recopila y brinda información 
sobre esta disciplina. Allí pueden 
encontrarse versiones demo de 
la mayoría de los softwares utili-
zados para generar visuales en 
tiempo real. <http://www.audio-
visualizers.com/>
En relación con la cuestión de integración de software con dispositivos 
electromecánicos resulta de vital importancia el campo de la robótica. 
Una referencia invaluable es el sitio Robots Argentina donde puede en-
contrarse todo tipo de información respecto de sensores, actuadores y 
dispositivos de control aplicados: <http://robots-argentina.com.ar/>
Arduino se convirtió muy rápidamente en la plataforma preferida por 
artistas y hobbistas para desarrollar interfaces de sensado y también 
como controlador para todo tipo de dispositivo electrónico desde pa-
neles de led hasta robots. <www.arduino.cc>
15
1.2.3. Los campos de acción: sensado, reproducción, generación y control
En función de lo anteriormente mencionado podemos intentar una separación conceptual de las partes que conforman 
el diseño de una instalación multimedial. Decimos “conceptual” puesto que es ingenuo pensar que cada una de estas 
partes puede implementarse por separado del resto. Eso, rara vez es posible ya que la instalación o dispositivo multime-
dial que estemos diseñando es en principio un sistema de partes aunadas que funcionan como un todo orgánico. Esta 
división tiene como fin poder realizar un estudio esquemático de los problemas asociados a este tipo de desarrollos.
Más allá del problema de interfaz eléctrico que significa poder introducir en la computadora parámetros que repre-
sentan magnitudes del orden de lo físico, lo verdaderamente importante del asunto es poder relacionar esos paráme-
tros con valores de control sobre el dispositivo informático; esto es: mapeo.
Estas traducciones y modificaciones de los valores para acondicionar las magnitudes de un espacio a otro (de lo físico 
a lo virtual) está dado por la inteligencia aplicada en las capas de software que median entre un valor y otro. Por eso, 
gran parte de este estudio estará dedicado a los procesos que se efectúan en la conversión de valores, por ejemplo, la 
velocidad de una mano que controla la intensidad con que se desplaza un objeto en la pantalla.
Muchas veces, este tipo de configuraciones implica el proceso de las señales para lograr describir tendencias en lugar 
de valores instantáneos (cómo varía tal magnitud en vez de su valor instantáneo).
Los caminos posibles para producir entornos virtuales son 
dos: reproducción de material pregrabado y generación 
en tiempo real por diversos medios. En el primer caso, el 
material audiovisual (y en todo caso sinestésico) está pre-
producido. Sonidos previamente editados y organizados 
pueden ser disparados en secuencias lógicas relacionales 
o en el devenir de los eventos de entrada desde el mundo 
exterior a modo de triggers (disparadores). 
Cuando hablamos de “generación en tiempo real” nos 
referimos a que el material virtual sea en principio una 
manifestación absolutamente original. En este caso, 
el software está diseñado para producir en tiempo 
real esas imágenes sinestésicas a partir de pautas de 
inteligencia artificial, sistemas de simulación física, o 
algoritmos de composición musical a partir de teorías 
matemáticas; situaciones muy frecuentes en la música 
electrónica contemporánea.
El protocolo MIDI es un estándar de 
comunicación para instrumentos 
musicales electrónicos desarrolla-
do a finales de la década de 1970 
por los principales fabricantes de 
instrumentos electrónicos. Es prác-
ticamente ubicuo en todos los sis-
temas de producción musical. Se 
pueden consultarmás detalles so-
bre MIDI en el sitio de la asociación 
de fabricantes que utilizan la nor-
ma: <http://www.midi.org>
16
Infinidad de dispositivos controladores salieron al 
mercado en los últimos años: perillas, botones, tecla-
dos y los más diversos sistemas con control inundan 
las vidrieras de las casas de videojuegos y electrónica. 
Muchos de esos dispositivos pueden ser hackeados y 
empleados de maneras innovadoras en los proyectos. 
Web cams, Controles MIDI, Wii Motes, Joysticks tradi-
cionales y en este último tiempo el Kinect de Microsoft 
aparecen en todo tipo de instalaciones interactivas 
muchas veces ocultos en escenografías especialmente 
diseñadas. Aprenderemos cómo desarrollar nuestros 
propios dispositivos de control a partir de estos y otros 
artefactos disponibles.
Un	controlador	muy	popular	y	original	utilizado	por	muchos	artistas	
es	el	Monome:	información	disponible	en	<http://monome.org/>
1.2.4. Lenguajes de programación y herramientas de control
La actividad artística mediada por dispositivos electrónicos, y en particular por ordenadores programables, trae apa-
rejadas dos grandes actividades propias de este medio.
Bien sabemos que la particular capacidad de una computadora es la de poder controlar de manera extremadamente 
precisa y rápida una inmensidad de parámetros. Esto las coloca como herramientas fundamentales para producir 
espacios inmersivos donde uno o varios performers u operadores pueden controlar diversos elementos en la escena.
Pero es también gracias a esas mismas características de precisión y velocidad que las computadoras pueden ser má-
quinas extremadamente útiles para generar entornos virtuales produciendo imagen y sonido de manera automática.
Estas dos grandes capacidades determinan, en consecuencia, tres grandes grupos de softwares: los que están pensa-
dos para controlar y/o modificar la reproducción de algún material multimedial preexistente, los que pueden generar 
materiales visuales y sonoros sintéticos y los que pueden realizar ambas tareas a la vez.
Recordemos que si bien hay muchos programas que, por ejemplo, pueden producir imágenes o bocetos con mode-
los tridimensionales, secuencias de sonidos o cualquier otro tipo de imágenes en general, solo nos interesan los que 
permiten ejecutar estos procesos en tiempo real.
Texto Aparte
Todos los softwares de hoy en día vinculados al multimedia y al arte y diseño en 
general traen incluidos algún sistema de scripting (pequeñas estructuras de código 
que se ejecutan en tiempo real, sin compilación) que permite introducir secuencias 
de código que son ejecutadas por el mismo programa o por alguna máquina vir-
tualizada dentro del mismo software (es el caso por ejemplo de Blender, el software 
de 3D que permite reprogramarlo completamente utilizando el lenguaje Python).
Es por eso que no podemos afirmar que un lenguaje sea mejor que otro ya que 
esto depende de las necesidades específicas de lo que se quiera realizar o de lo que 
ya nos es dado por los sistemas existentes.
17
1.2.5. Taxonomía del software de los sistemas interactivos en el arte
En relación con lo anterior, intentaremos ahora una discriminación bien estructural de los diversos sistemas de soft-
ware disponibles que utilizaremos, en función de cuál es el tipo de aproximación que el usuario puede tener. Esto se 
traduce fundamentalmente en el grado de abstracción que tal o cual software permite a la hora de realizar nuevas 
operaciones. Es decir, por un lado tenemos disponibles lenguajes completos de programación y entornos de desarro-
llo específicos para diseño y producción de arte visual y sonoro. Y en el otro extremo tendremos softwares prediseña-
dos, esto es: cerrados, cuya funcionalidad específica es provista por el creador y no admite la modificación sustancial 
de las funciones originales (pero sí su manipulación).
Nos interesa, entonces, hacer una diferenciación de estas herramientas según un criterio arbitrario. Este criterio res-
ponde a los tipos de aplicaciones que consideramos más relevantes para nuestra disciplina. A lo largo del material 
intentaremos describirlos:
• Sistemas de generación y control de sonido e imagen en tiempo real. 
• Sistemas ópticos de captura de movimiento (MoCap). 
• Sistemas de análisis de contenido (Blob Detection).
• Protocolos de comunicación (OSC).
Muchas de las herramientas de VJ (como vimos, VJ es la interpretación de imagen en tiempo real análogo a un DJ) se 
encuadran dentro de la primera categoría, ya que son aplicaciones que permiten asociar la ejecución (reproducción) 
de contenidos visuales (imágenes estáticas, videos o animaciones) a ciertos eventos, así como controlar la forma en 
que se les aplica efectos a estos contenidos. 
En el conjunto de las herramientas para reproducción y control en tiempo real, podemos encontrar algunas de las 
aplicaciones para VJ como Arkaos, Resolume, VDMX y Modul8, entre otros.
Imagen 1.4. Pantalla principal de Arkaos
Fuente: imagen extraída de <http://www.arkaos.net/>
18
En la imagen anterior (1.4.) se muestra la interfaz gráfica de Arkaos. Como puede verse, Arkaos se encuadra dentro de 
la metáfora de la consola, ya que su interfaz gráfica está diseñada como un conjunto de paneles en los que el usuario 
puede organizar el material (los videos, animaciones, efectos, etc.) y decidir a qué eventos los asocia, como sucede 
en el panel inferior en el que aparece un teclado (con disposición de teclado de piano) en el que el usuario acomoda 
los videos que ejecutará con cada tecla. También se pueden ver varios controles gráficos que imitan potenciómetros 
lineales que servirán para configurar parámetros de la reproducción y de los efectos que se aplican durante la misma.
Texto Aparte
Pasamos entonces a una breve descripción de cada una de estas herramientas:
Arkaos
<http://www.arkaos.net>
Versión Actual: Grand VJ.
Arkaos es un producto desarrollado en Bélgica, que permite manipulación de vi-
deo en tiempo real, es decir que puede tomar diversos archivos de video (o ma-
terial animado incluyendo composiciones de Quartz Composer –del que habla-
remos en el siguiente apartado–, imágenes fijas y máscaras. Puede trabajar con 
hasta ocho capas de video en simultáneo. Posee posibilidad de comunicación MIDI 
(protocolo de comunicación que será descripto en los siguientes apartados) en dos 
direcciones. 
Resolume
<http://www.resolume.com/avenue/>
Versión Actual: 3.0
Resolume, desarrollado en Holanda, está íntegramente escrito en C++ utilizando 
librerías OpenGL, esto quiere decir que posee un motor de imagen en tiempo real 
de una excelente performance. Puede manejar capas de video en HD y además 
tiene integrado un completo reproductor de audio. Reproduce varios formatos, 
cuenta con un Analizador de Audio integrado, está pensado para poder realizar 
Video Mapping fácilmente. Soporta múltiples pantallas y además posee la posibi-
lidad de conectividad. En la nueva versión 3, el código de Resolume fue reescrito 
desde cero (from	scratch). Sus desarrolladores aseguran que esta no es solo una 
versión mejorada de la original sino que a su vez está pensada desde un nuevo 
paradigma tecnológico que tiene relación con la posibilidad de que el software se 
siga expandiendo en posibilidades conforme se vaya desarrollando y mejorando 
las capacidades de los hardwares gráficos.
VDMX
<http://vidvox.net/>
Versión actual: 5
Las prestaciones son aproximadamente similares a los dos softwares anteriores. 
Una de las ventajas que tiene este, por sobre otros, es que permite la ejecución 
de varias acciones en paralelo en forma independiente en procesadores de varios 
núcleos mediante una estrategia llamada “multihilo” (multi	thread), con lo cual el 
rendimiento en tiempo real se ve extremadamente mejorado. Además, VDMX se 
publicita como la opción más “amiga” de Quartz Composer.
19
Modul8
<http://www.modul8.ch/>
Versión actual: 2.6.4
Modul8 es el más versátil de toda la línea ya que fue diseñado principalmente por 
visualizadores, vjs y artistasvisuales. Sus desarrolladores son Suizos. Modul8 inte-
gra todo un espacio escénico: múltiples pantallas, sonido y además la posibilidad 
de integrar sistemas de control de luces con estándar DMX (un protocolo de comu-
nicación para iluminación escénica). Sus desarrolladores también crearon actual-
mente un software muy popular para diseño de mappings llamado “MadMapper” 
(<www.madmapper.com>).
Ableton’s Live
<http://www.ableton.com/live-8>
Versión Actual: Ableton Live 8
Esta herramienta no pertenece en sí al mundo del VJ sino que es su equivalente 
musical. Live es en realidad una suite de programas, esto es un compilado de pro-
gramas todos funcionando entre sí para convertir la computadora en una estación 
de trabajo musical y performático completa.
La principal virtud de Live es que puede, a la vez que reproduce secuencias de au-
dio pregrabadas, ejecutar secuencias MIDI que controlan sintetizadores y samplers	
virtuales que corren en el mismo sistema por medio del estándar VSTi.
Otra de las grandes virtudes que hicieron a Live tan popular es que cuenta con al-
goritmos de Time	Stretching sofisticados muy valorados por los artistas provenien-
tes del DJ’ing	o la música electrónica. Live puede controlar y a la vez ser controlado 
tanto por otros softwares como mediante el uso de controladores discretos que se 
conectan al ordenador por USB.
Como se dijo anteriormente todas estas aplicaciones son cerradas, es decir que las 
posibilidades de modificación corren solo por cuenta de sus desarrolladores.
También encontramos lenguajes de programación para contenidos multimediales que nos permitirán construir nues-
tras propias herramientas con funciones particulares. Estos lenguajes de programación permiten que el usuario defi-
na (muchas veces desde cero) cómo se orquesta la reproducción o generación de los contenidos. 
En estos sistemas impera la lógica del algoritmo bajo dos modalidades: la primera corresponde a los entornos visua-
les en los que el usuario configura una red de objetos que se comunican entre sí procesando de diferentes formas la 
información.
Este tipo de entornos de programación se denominan “visuales” ya que la codificación de la secuencia lógica de fun-
cionamiento se realiza a través de un entorno gráfico donde las funciones están representadas fundamentalmente 
por objetos interconectables. Cada uno de estos objetos tiene una serie de conexiones preestablecidas que toma o 
devuelve (según sea el caso) tipos de datos específicos.
Cada objeto en cuestión está preparado para resolver una tarea muy concreta, lo que permite una gran flexibilidad de 
interconexión con el resto de los objetos con el fin de conseguir una funcionalidad más compleja.
20
Imagen 1.5. Interfaz de max/MSP
Fuente: imagen extraída de <http://cycling74.com/>
La imagen anterior (1.5.) muestra la interfaz gráfica de Max/MSP, un entorno de programación visual cuya evolución 
tiene ya casi 25 años. Como puede verse en el esquema de la parte izquierda, el algoritmo está organizado en un 
conjunto de objetos, representados por los cuadros con texto en su interior, que están conectados entre sí por ca-
bles, expresados por las líneas. La idea consiste en procesar información mediante su paso a través de los diferentes 
objetos. En el caso de Max/MSP la información va de arriba hacia abajo, por ejemplo en la imagen, parte del proceso 
se inicia en el objeto de arriba, que tiene el icono del micrófono, y termina en los objetos ubicados en la parte inferior 
como el que tiene el dibujo del parlante. 
Debido a que de un objeto pueden surgir varios “cables” y que otros objetos pueden aceptar varias conexiones como 
entrada, este paradigma de programación suele privilegiar ciertas estrategias de proceso en paralelo. Además, por 
su lógica de flujo, facilita la programación de aquellos algoritmos que pueden ser pensados como una secuencia de 
procesos (o filtros) transformadores aplicados uno a continuación de otro, por ejemplo, en un flujo de sonido o video. 
Por otra parte, se tiene cierta desventaja cuando se quiere programar estrategias que implican cambios de estados en 
el tiempo, particularmente si estas llevan a complejos bucles de retroalimentación.
Dentro de este tipo de entornos de programación podemos nombrar a MaxMSP, Pure Data, VVVV, Quartz Composer, 
entre otros.
21
Texto Aparte
Pasamos entonces a una breve descripción de cada una de estas herramientas:
Max/MSP y Pure Data
<http://cycling74.com/whatismax/spanish/>
Versión Actual: Max 6
Desarrollado en el IRCAM (Institut de Recherche et Coordination Acoustique/Mu-
sique) por Miller Puckete este software para control, en principio, y generación de 
audio digital, después, es central en las artes multimediales ya que fue lo que po-
sibilitó que muchos artistas pudiesen explorar tempranamente la creación de en-
tornos interactivos. Luego de que Cycling 74 comprara el proyecto max/MSP y lo 
desarrollara como producto comercial, Puckete lanzó a la comunidad de software 
libre la versión libre del Pure Data. Max/MSP o Pure Data con entornos gráficos en 
los cuales uno puede desarrollar sintetizadores o estructuras de control complejas 
para controlar aparatos MIDI de manera visual conectando objetos unos con otros.
Existen también aplicaciones visuales que permiten programar comportamientos 
de manera gráfica. De hecho, Max/MSP tiene su módulo particular destinado al 
manejo de imagen llamado Jitter (cuyo análogo en el mundo Pure Data es GEM). 
Este módulo permite desarrollar todo tipo de proyectos donde lo central es la ima-
gen en movimiento y el análisis posterior de dicha imagen. Jitter puede ser utiliza-
do tanto para resolver cuestiones de visión por computadora como para producir 
de manera algorítmica diferentes tipos de contenidos visuales, ya sea procesando 
imagen prediseñada o produciéndola de manera generativa. 
De más está decir que ambos mundos (el visual y el sonoro) pueden convivir en la 
misma aplicación con lo cual Max/MSP + jitter (o PD+Gem) pueden ser entornos 
muy adecuados para resolver instalaciones en donde se requiere que el sonido y la 
imagen funcionen de manera sincrónica.
VVVV
<http://vvvv.org/tiki-index.php>
Versión Actual: 40beta23
VVVV es un sintetizador de video en tiempo real e interacción con interfaces físicas. 
Está solo disponible para Windows ya que su motor gráfico está construido sobre 
la librería DirectX propia de ese sistema operativo. Es 100% tiempo real (no tiene 
modos build/run) y además es software libre y recientemente Open Source.
Quartz Composer
<http://en.wikipedia.org/wiki/Quartz_Composer>
Versión Actual: 4 (para Mac OS 10.6 Snow Leopard)
Quartz Composer es un lenguaje de programación visual basado en nodos provis-
to como parte del kit de desarrollo para el sistema operativo OSX. Es solo para Mac, 
basado 100% en OpenGL y permite programar filtros de imagen. Además, tiene 
un objeto que permite introducir código en lenguaje Javascript (de uso común en 
sitios de Internet) y otro que permite modelar Shaders (lenguaje de programación 
para el procesador gráfico) utilizando el lenguaje GLSL.
22
Si bien el Massachusetts Institute of Technology (MIT) tiene una larga tradición ligada a la producción de sistemas y 
lenguajes para la enseñanza de la informática en distintos niveles, no es hasta la aparición de Processing que los ar-
tistas visuales o realizadores pudieron comenzar a desarrollar de manera prolija y sistemática sus trabajos utilizando 
código de computadora. Processing es en principio un lenguaje de programación diseñado para poder bocetar de 
manera rápida ideas visuales en un contexto informático. Es libre de ser distribuido y además es de código abierto, es 
decir, que cualquiera que esté interesado puede acceder a su código fuente para ver cómo está internamente progra-
mado. Esto permite además optar por modificarlo o extenderlo según una necesidad particular. 
Processing (abreviado P5) es en gran medida el origen de una serie de desarrollos que se fueron desencadenandobajo este concepto para acercar a artistas en general, herramientas que hasta ese momento estaban solo disponibles 
para aquellos que tuviesen los conocimientos necesarios para poder adentrarse en la informática y en la microelec-
trónica. La plataforma de hardware libre Arduino es otro ejemplo de ello.
Imagen 1.6. Sitio web de Processing
Fuente: imagen extraída de <http://processing.org/>
En ese sentido P5 es el más “cuidado” de todos los lenguajes de programación asociados a las artes visuales. Existen 
otros lenguajes con mayor desarrollo pero que se encuentran ligados a una función comercial particular, por ejemplo 
AS3 Flash. Estos lenguajes fueron específicamente diseñados a partir de una necesidad técnica muy concreta: animar 
la web. Processing a su vez fue creado con una intención didáctica, esa es la razón principal por la cual es de código 
abierto.
Como referencia tanto histórica como específica del lenguaje Processing 
recomendamos la lectura del libro Processing a Programming Handbook 
editado por Mit Press con prólogo de Joe Maedea, quien fuera profesor 
de Ben Fry y Casey Reas, iniciadores del proyecto Processing. P5 es re-
sultado de uno de sus trabajos en laboratorio de investigación en el MIT.
Un resumen de toda la funcionalidad de P5, explicada de forma sintéti-
ca y clara por sus creadores puede encontrarse en 
<http://processing.org/learning/overview/>
Algunas de las librerías más utilizadas son “minim” para captura y análi-
sis de audio, “BlobDetection” para análisis de contenido en la imagen y 
“Firmata” para interactuar con un dispositivo Arduino.
<http://processing.org/reference/libraries/>
23
P5 es, como ya dijimos, un completo lenguaje de programación gráfica pero también un entorno de desarrollo por el 
cual uno puede producir aplicaciones ejecutables (como cualquier otro programa en nuestro ordenador) a partir del 
código escrito en lenguaje P5. 
El proceso de confección de una aplicación consiste en generar el código con las instrucciones necesarias en lenguaje 
comprensible por el ser humano para luego ser convertido (compilado) al lenguaje de la máquina. Processing resuel-
ve este proceso que suele ser en algunos casos muy complicado de manera automática y sencilla: basta apretar play	
(run) para que nuestro programa corra en la pantalla. 
El éxito de P5 fue tal que el número de usuarios globales del sistema creció exponencialmente año tras año y aún hoy 
se mantiene la tendencia. En gran parte esto se debe al gran número de librerías que fueron apareciendo para sortear 
diferentes problemas específicos de los usuarios de Processing.
Una librería es un paquete de software que se puede utilizar para resolver alguna cuestión específica como comuni-
carse con una cámara web sin necesidad de saber específicamente nada sobre la cámara. Otras librerías están des-
tinadas a solucionar, por ejemplo, problemas de orden gráfico, es decir, cómo se puede realizar una operación de 
procesamiento visual de manera rápida y prolija. Hay en este momento varios cientos de librerías avaladas por los de-
sarrolladores de P5 que aceleran el proceso de creación de software visual para entornos interactivos. Veremos varias 
de ellas a lo largo de este material y analizaremos un caso particular creado exclusivamente para resolver el problema 
de la captura de movimiento en una escena.
Texto Aparte
Varios proyectos tomaron la intención original de Processing y dieron forma a nue-
vas maneras de acceder a la informática de modo más o menos sencillo. Arduino 
es una plataforma de hardware libre por la cual se puede programar un microcon-
trolador de manera sencilla. Un microcontrolador es un dispositivo electrónico (un 
chip) que tiene incluidas todas las partes de una computadora completa, es decir 
un CPU, una memoria RAM para ejecutar los programas, una memoria ROM para al-
macenar el programa, una memoria Eprom que permite mantener los datos guar-
dados luego de la interrupción de la energía de alimentación y entradas y salidas 
digitales y analógicas. <www.arduino.cc>
Las visuales de la película Tron	
Legacy (2010, EE.UU.) dirigida por 
Joseph Kosinski fueron realizadas 
utilizando openFrameworks. Se 
pueden ver en el siguiente enla-
ce: <http://jtnimoy.net/?q=178>
24
Como referencia a otros lenguajes de programación y entornos para la computación gráfica interactiva mencionare-
mos solo dos:
openFrameworks: aparece como una alternativa a Processing para aquellos realizadores que además poseen un co-
nocimiento más avanzado en programación o que ya hicieron sus primeros pasos en Processing y ahora sus aplica-
ciones requieren de mayor rendimiento o del uso de piezas de software no disponibles en Java (que es el lenguaje 
original sobre el cual está escrito Processing).
openFrameworks es también de código abierto y con una comunidad creciente muy efervescente que produce en 
conjunto una cantidad de software increíblemente alta, versátil y ecléctica. Esto se realiza por medio de “addons” que 
en definitiva serían el análogo a las librerías de Processing. 
La diferencia fundamental entre openFrameworks y P5 es que openFrameworks está escrito en lenguaje C++ y no 
tiene un editor de código asociado lo que hace el proceso de fabricación de aplicaciones un poco menos directo que 
en Processing. 
Una vez superada esta primera instancia de puesta a 
punto del entorno de trabajo, las aplicaciones generadas 
suelen correr más rápido que en Processing por ser C++ 
un lenguaje no interpretado. Esto significa que el códi-
go de máquina generado es particular para el sistema 
operativo en el cual se trabaja mientras que el código de 
máquina generado por Processing es interpretado por 
una “máquina virtual” que es la que en definitiva interac-
túa con el sistema operativo. Es por eso que el código de 
Processing es multiplataforma ya que ese mismo código 
es susceptible de ser ejecutado en cualquier ordenador 
que tenga instalada una Java Virtual Machine.
Imagen 1.7. Visual de la película Tron Legacy
Fuente: imagen extraída de http://jtnimoy.net/?q=178
25
El otro framework	que se ha puesto “de moda” en estos últimos tiempos es Cinder. Está también escrito en C++ y su 
particularidad es que el core (núcleo), o sea, la rama central de código, está prolijamente mantenida por su creador 
Andrew Bell. Cinder aparece como un entorno de desarrollo de aplicaciones gráficas pero orientado al segmento 
profesional y se presenta como una librería de código organizada de manera lógica e intuitiva al realizador gráfico.
Andrew Bell
<http://drawnline.net/>
Cinder
<http://libcinder.org/>
1.2.6. Sistemas operativos
Si bien no es la intención de los autores de este material postular la idea de que un sistema operativo es mejor que 
otro, es válido mencionar que históricamente el sistema operativo Mac fue y es el que va a la vanguardia en cuanto a 
multimedia se refiere. Es por eso que muchas de las aplicaciones más sofisticadas, versátiles y estables en términos de 
performance y actualizaciones están solo disponibles para ese sistema operativo
Es también válido mencionar que en su origen el sistema operativo Mac Os Classic permitía a los desarrolladores generar 
aplicaciones de manera muy sencilla. Había una clara intensión de la empresa Apple de producir no solo computadoras 
sino de permitirle a sus usuarios que produzcan software compatible con su ordenador de la manera más cómoda e 
inmediata posible. No es casual que la primera versión de max/MSP fue escrita para la computadora Macintosh.
Max/MSP
<http://en.wikipedia.org/wiki/Max_(software)>
Otra opción interesante en nuestro campo es GNU/Linux, un sistema operativo completo de código abierto y libre. 
Por tratarse de un sistema operativo libre en la que una gran cantidad de desarrolladores globales se encuentran 
trabajando cotidianamente, suelen aparecer soluciones muy inmediatas a problemas relacionados con nuevas inter-
faces o dispositivos. 
La comunidad de software libre trabaja con ese tipo de software por lo tantoes más probable que desarrollos libres 
provengan desde ese lugar más que desde un sistema cerrado. Por ese motivo es muy común hoy día encontrar sis-
temas GNU/Linux en gran cantidad de dispositivos multimedias como RaspberriPI y otros.
La	versión	mas	conocida	de	GNU/Linux	es	Ubuntu:
<http://www.ubuntu.com/>
1.2.7. Sistemas ópticos de sensado de posición y silueta
Estos sistemas son técnicas, algoritmos y herramientas que utilizan videocámaras para observar una escena y extraer 
información a partir del análisis de la imagen captada por este dispositivo. Generalmente, estos algoritmos implican 
el análisis de la imagen píxel por píxel para extraer información que de cuenta de aspectos de la escena tales como el 
movimiento de una persona, la presencia de ciertos objetos u otras variables. 
Algunos ejemplos:
TSPS permite capturar la entrada de personas en la escena:
<http://opentsps.com/>
reactiVision es utilizado para resolver pantallas táctiles. Constituye una 
parte importante del proyecto reacTable:
<http://reactivision.sourceforge.net/>
CCV está pensado para resolver sistemas de pantallas multitouch a gran 
escala: <http://ccv.nuigroup.com/>
Ejemplo de proceso de captura de movimiento:
Imagen 1.8. Captura por sustracción de fondo
Fuente: elaboración propia
26
Las técnicas pueden ser aplicadas mediante la implementación de sus algoritmos en algún lenguaje de programación 
como los anteriormente descritos, pero también existen herramientas de software que ya tienen resuelto el algorit-
mo y que solo deben ser puestos en funcionamiento para que brinden la información que deseamos obtener de la 
escena.
Los sistemas ópticos de sensado de posición y silueta han adquirido una gran relevancia en los sistemas interactivos, 
dado que es un tipo de sensado más sencillo y eficaz. Es, además, menos costoso que el sensado por medios físicos 
de los mismos fenómenos. 
En el arte interactivo vinculado a la multimedia escénica (instalaciones interactivas, performance, etc.), este tipo de 
sensado es de gran utilidad ya que nos permite captar el movimiento del cuerpo mediante la utilización de cámaras 
de bajo costo como lo son las cámaras web.
 
Ejemplo de proceso de captura de movimiento:
Imagen 1.9. Resultado de la captura
Fuente: elaboración propia
27
Este tipo de sistemas también ha habilitado la construcción de pantallas sensibles al tacto, multitacto (es decir, que 
pueden captar varios dedos a la vez). Por un lado, en formato de pantallas de acrílico, retroproyectada, como las crea-
das por Jefferson Han que aprovechan un fenómeno óptico llamado Reflexión total interna frustrada. Este fenómeno 
permite que se ilumine un acrílico en los cantos cuando se apoya un dedo sobre la superficie del acrílico, la yema del 
dedo se iluminará, luego una cámara captará dicha luz e interpretará la posición del dedo.
 
Imagen 1.10. Imagen del efecto de la Reflexión total interna frustrada 
Fuente: imagen obtenida de <http://cs.nyu.edu/~jhan/ftirsense/>
Pantallas sensibles al tacto, multitouch en tela de lycra retropro-
yectada: estas pantallas permiten trabajar con mayores tamaños. 
En este caso, se utiliza retroproyección para generar la imagen y 
el sistema óptico capta la sombra que generan los dedos al hun-
dir la tela.
28
Imagen 1.11. Imagen de las pantallas sensibles al tacto multitacto hecha por Jefferson Han 
Fuente: imagen obtenida de: <http://cs.nyu.edu/~jhan/ftirsense/>
El siguiente video muestra las imágenes de las pantallas sensibles al tacto multitacto hechas por Jefferson Han.
Fuente: obtenido de: <http://cs.nyu.edu/~jhan/ftirsense/>
 
29
Imagen 1.12. Imagen de la obra Sensible
Fuente: gentileza del colectivo Proyecto Biopus <www.biopus.com.ar>
Imagen 1.13. Imagen del sistema de la obra Sensible
Fuente: gentileza del colectivo Proyecto Biopus <www.biopus.com.ar>
30
Imagen 1.14. Análisis de imagen realizado por el sistema de pantalla sensible al tacto con tela de Lycra
Fuente: gentileza del colectivo Proyecto Biopus <www.biopus.com.ar>
Fuente: Sensible (2007), Instalación interactiva del Proyecto Biopus <www.biopus.com.ar>
Una versión más refinada de los sistemas ópticos de captación 
son aquellas que permiten interpretar determinados patrones 
visuales en la imágenes provenientes de la cámara. Existen técni-
cas y algoritmos destinados a captar patrones bitonales (en blan-
co y negro) en la escena. La idea consiste en colocar a objetos físi-
cos etiquetas con patrones bitonales de forma que estos puedan 
ser captados por el sistema y así poder deducir la ubicación del 
objeto físico en la escena.
Estas técnicas pertenecen al campo de la realidad aumentada 
que implica la vinculación con entidades virtuales mediante la 
manipulación de objetos físicos, y por ende, su forma de puesta 
en escena busca la integración perceptiva de las entidades vir-
tuales con el entorno físico.
Imagen 1.15. Imagen de un sistema de Realidad aumentada
Fuente: imagen obtenida de 
<http://www.interaction-design.de/tag/hci/>
31
1.2.8. Protocolos de comunicación
Dada la gran complejidad de las tareas que un sistema interactivo debe contemplar para poder generar una expe-
riencia inmersiva, dinámica, en tiempo real de calidad, surge la necesidad de hacer que muchos softwares a la vez 
interactúen tanto localmente (en un mismo ordenador) como de forma remota (vía red).
Esto es algo que a los músicos electrónicos les ocupa desde el origen mismo de la disciplina. Los grandes sistemas 
modulares de la década de 1950 comunicaban información de un módulo a otro utilizando un sistema analógico 
denominado control por voltaje. El control por voltaje permite que varios instrumentos musicales funcionen en con-
junto, de esa manera, un mismo teclado puede estar controlando a la vez un oscilador y disparando una envolvente 
para generar la dinámica acorde con el sonido que se intenta sintetizar.
<http://es.wikipedia.org/wiki/MIDI>
32
Imagen 1.16. Sintetizador Moog Modular
Fuente: imagen extraída de <http://www.sequencer.de/syns/moog/Modular.html>
Esta idea es tomada luego por los fabricantes de instrumentos musicales digitales para desarrollar la norma de comunica-
ción MIDI que será la base de los protocolos y sistemas de comunicación con los cuales trabajaremos a lo largo del material.
El protocolo de comunicación MIDI nace a principios de la década de 1980. Desarrollado por varias empresas fabri-
cantes de equipos musicales. Propuesto inicialmente por Dave Smith de Sequencial Circuits, pretendía ser el estándar 
de comunicación establecido para que cualquier instrumento musical electrónico digital pudiese comunicarse (com-
partir información) con otros sin importar el tipo de artefacto, modelo o fabricante.
De hecho, el estándar MIDI se impuso con tal fuerza que hasta el día de hoy (40 años más tarde) sigue vigente, sin 
duda debido a la simpleza de su implementación.
Un “estándar” no es más que una “definición”. En el caso de los estándares de comunicación entre artefactos digitales 
esa definición comprende esencialmente dos partes: una referida a la capa física, el “cómo” y otra referida a la capa 
lógica, el “qué”.
En el caso del protocolo MIDI, el estándar prevé que la comunicación entre dispositivos esté soportada por una co-
nexión serial donde los artefactos intervinientes se encuentren aislados eléctricamente pero donde se mantenga un 
vínculo de circuito cerrado entre el que recibe y envía. Es lo que se conoce como un loop de corriente.
El dispositivo que emite un mensaje MIDI envía una corriente eléctrica que modula un diodo infrarrojo en el receptor. 
Esa variación es interpretada internamente por el receptor quien es el encargado de “descifrar” el mensaje con base 
en un código binario establecido de antemano que en el caso de MIDI se transmite a una velocidad de 31250 bits por 
segundos (o baudios).
En lo que concierne a la capa “lógica” del protocolo, se establecen mensajes donde la información efectivamente 
transmitida es de 7 bits, esto representavalores de entre 0 y 127. La combinatoria de varias de estas “palabras” se es-
tablece también en el protocolo, el cual permite, por ejemplo, transmitir usando tres palabras: información respecto 
de qué nota está siendo ejecutada en un teclado como también con qué valor de intensidad la tecla ha sido percutida 
(siempre en valores que van de 0 a 127).
En Windows se puede utilizar el programa midiYoke para virtualizar 
puertos midi: 
<http://www.midiox.com/index.htm?http://www.midiox.com/myoke.htm>
Sobre OSC se desarrollaron protocolos específicos de la actividad au-
diovisual y de las interacciones en tiempo real entre dispositivos. Tal es 
el caso del protocolo TUIO utilizado para implementar de manera están-
dar aplicaciones de interacción multitouch. <http://www.tuio.org/>
33
En nuestro trabajo encontraremos que muchas veces se utilizan interfaces o dispositivos que responden a esta norma 
como software que puede ser controlado a partir de este protocolo tanto desde un dispositivo interno como por otro 
software. En este caso la capa física de conexión permanece virtualizada internamente en el sistema operativo.
Si bien la potencia y flexibilidad del protocolo MIDI es indiscutible, con el tiempo surgió la necesidad de mejorar ese 
estándar de comunicación pensando ya en la conexión de diferentes instrumentos musicales (fundamentalmente 
software que corra en un ordenador) ampliando en principio la posibilidad de mensajes que se pueden enviar, su 
largo de palabra (se refiere a cuán grande es el rango de posibilidades que puede transmitir), la velocidad de transfe-
rencia y la implementación de mensajes específicos creados por el usuario final. Como respuesta a esta demanda es 
que surge el protocolo OSC.
OSC (opensoundcontrol) es un protocolo cuyo estándar físico está basado en otro protocolo familiar a las compu-
tadoras que es TCP usado en las conexiones de red. OSC funciona sobre TCP utilizando paquetes en otro protocolo 
denominado UDP. Este último permite despachar mensajes desde un servidor y todos los clientes que escuchen a ese 
servidor en un puerto determinado pueden recibir el mensaje.
Web	de	OSC
<http://opensoundcontrol.org/introduction-osc>
Los mensajes se establecen según tipos de datos específicos: números enteros, decimales, cadenas de caracteres o 
arreglos que incluyen listas de algunos de ellos. El protocolo también prevé que los mensajes lleven una especie de 
“encabezado” que identifique el tipo de mensaje, de manera que quien lo reciba, conociendo de antemano la especi-
ficación para ese tipo de mensaje, pueda entenderlo y utilizarlo en consecuencia.
1.2.9. Hardware de los sistemas interactivos: sistemas de control y sensado físico
Así como el proyecto Processing encarna cierta revolución respecto del uso de computadoras por parte de artistas 
para poder generar imágenes utilizando código, el proyecto Arduino intenta acercar al mismo público el uso de mi-
crocontroladores de manera ágil y sencilla sin mayores complicaciones.
Un microcontrolador es una pequeña computadora integrada en una pastilla (chip). Contiene en su interior todas las 
partes de un ordenador pero de manera reducida. En el caso de Arduino el microcontrolador a utilizar es alguno de 
la marca AVR y que en general cuenta con las siguientes prestaciones: un CPU corriendo a 16Mhz, memoria RAM de 
34
328 bytes, una memoria de programa ROM (es decir, que no se borra al desconectarlo de la corriente) de 32KB, una 
memoria eprom (que se puede autograbar y se mantiene luego del corte de energía) y diversos dispositivos como 
una interfaz de comunicación serial, generador de señales con modulación del ancho de pulso (PWM) y lo más impor-
tante, puertos de entrada y salida digitales y analógicos.
Estos puertos nos permiten conectar Arduino con casi cualquier otro dispositivo electrónico (generalmente por me-
dio de algún otro circuito de interfaz) de manera de poder controlarlo remotamente tanto por medio de un software 
precargado o utilizando el propio Arduino como interfaz entre un ordenador y el aparato que se requiera controlar.
Los puertos son además bidireccionales de modo que podremos usarlos tanto como salida (si es que queremos con-
trolar algo externo) o como entradas en el caso de que necesitemos utilizar sensores. Arduino (la comunidad y el pro-
yecto en sí) prevé este tipo de usos por lo cual la extensa documentación en su web hace en gran parte su existencia. 
35
2. Imagen y sonido en tiempo real
 
Objetivos
• Conocer y dominar las herramientas de software y hardware más usadas.
• Vincular diversas aplicaciones de imagen y sonido entre sí conociendo los protocolos más utilizados.
• Construir un sistema de generación de imagen a partir de sonido.
2.1. Introducción
En esta unidad presentaremos los bloques fundamentales con los cuales producir una pequeña aplicación interactiva 
que pueda generar imagen a partir del sonido. El hecho de poder vincular de manera creativa la imagen y el sonido 
para producir un acontecimiento audiovisual interactivo original es central para nuestra disciplina. Consideramos, por 
ese motivo, que intentar construir una aplicación de este estilo es un buen punto de partida para comenzar a descu-
brir los detalles de las tecnologías involucradas en nuestro curso de manera progresiva.
Utilizaremos los programas Pure Data (PD) para la captura y análisis de la señal sonora y Processing (P5) para crear un 
motor visual que genere imagen a partir de ciertos parámetros. En la siguiente unidad explicaremos los pormenores 
acerca de cómo vincular las dos aplicaciones para que funcionen de manera unitaria utilizando el protocolo OSC o MIDI.
Un ejemplo muy claro en este sentido es la obra Messa Di Vocce del colectivo artístico Flong
Fuente: <http://www.youtube.com/watch?v=STRMcmj-gHc>
2.2. La computadora personal como herramienta
Con la aparición de la computadora personal (en el año 1976 aproximadamente) comenzó también el desarrollo de 
software para esos dispositivos. Hasta ese momento, todo el software era escrito en las universidades con propósitos 
fundamentalmente científicos. Grandes mainframes llenaban pisos enteros donde cada científico interesado en acce-
der al recurso tenía que compartir el tiempo de procesamiento con el resto de sus colegas.
El diccionario IBM de la computa-
ción define mainframe como “una 
gran computadora, en particular 
una a la cual otras computadoras 
pueden conectarse para poder 
compartir las funcionalidades que 
ese mainframe provee (por ejem-
plo, una computadora de la línea 
System/370 a la cual computa-
doras personales son conectadas 
para poder subir o bajar progra-
mas o datos). El término, general-
mente, se refiere solo al hardware, 
es decir, al almacenamiento prin-
cipal, los circuitos de ejecución y 
las unidades periféricas”. Fuente: 
<http://www-03.ibm.com/ibm/
history/exhibits/mainframe/main-
frame_intro.html>
Recién en el año 1983, Richard Stallman acuña el término “software libre 
(free software)” al determinarse a generar un sistema operativo de ca-
rácter libre (el sistema GNU). En palabras de Stallman Free software no 
significa “software gratuito” sino “software libre”.
“Libre”, en el sentido de ser considerado un bien común para la huma-
nidad y por tanto de ser tratado como cualquier otro bien cultural que 
la humanidad haya conseguido a lo largo de su evolución. (Stallman, 
1983: <http://www.gnu.org/philosophy/free-sw.html>)
Una analogía pertinente podría ser la siguiente: alguien, en algún 
momento, entendió cómo fabricar una pared. Con paredes se pueden 
construir casas. Ahora bien, el constructor de casas no paga regalías al 
inventor de la pared puesto que ese conocimiento forma parte del acer-
vo cultural de la humanidad. Con el software libre ocurriría más o menos 
lo mismo. La diferencia radica en que el software aparece ya en un mun-
do que se rige por las leyes del mercado y la industria.
36
En esos momentos, el tiempo de respuesta de las compu-
tadoras era sustancialmente másrápido que el de la men-
te humana. La computadora podía resolver problemas 
específicos de manera precisa y en tiempos mucho más 
cortos que los que tomaría a un calculador humano. De 
cualquier forma, es interesante tener en cuenta que cada 
calculación susceptible de ser llevada a cabo en la compu-
tadora podía tomar decenas de horas en resolverse. 
A partir de la entrada de las computadoras en las casas 
de los amateurs y aficionados a la computación es que 
también se dispara el desarrollo y el entusiasmo por 
conseguir aplicaciones que resolvieran los problemas 
e inquietudes de los nuevos propietarios de hardware: 
el usuario general.
Esos softwares, producidos ya fuera de las universidades, 
apuntaban a resolver tareas simples como llevar adelan-
te la contabilidad hogareña, calcular fácilmente presu-
puestos para pequeños negocios, manipular texto, emu-
lar juegos de ingenio y organizar agendas de contactos. 
Muy rápidamente las aguas se dividieron en dos grandes grupos: por un lado estaban quienes se juntaban a compar-
tir sus programas de manera amistosa en clubes informáticos y casas de computación. Eran comunes las reuniones de 
fin de semana donde se intercambiaban de manera impresa el código escrito para tal o cual máquina y que cumplía 
de forma más o menos certera con alguna función particular.
Por otro lado, también estaban quienes sostenían que el trabajo efectuado en resolver e implementar tal o cual algo-
ritmo debía ser tratado como un bien material sujeto a las leyes del mercado, es decir, susceptible de ser “comerciali-
zado”. Nace así el software privativo y la idea de software licenciado. 
Por supuesto, ambas vertientes tienen sus particularidades.
El código fuente (en inglés sour-
ce	code) es un conjunto de líneas 
que conforman un bloque de tex-
to, escrito según las reglas sintác-
ticas de algún lenguaje de pro-
gramación destinado a ser legible 
por humanos. Es un programa en 
su forma original, tal y como fue 
escrito por el programador, no es 
ejecutable directamente por el 
computador, debe convertirse en 
lenguaje de máquina mediante 
programas compiladores, ensam-
bladores o intérpretes. Poco tiem-
po atrás, la empresa Apple donó 
el código del sistema operativo 
que venía incluido en su modelo 
Apple II al museo de historia de 
la informática: <http://www.com-
puterhistory.org/atchm/apple-ii-
dos-source-code/>
Es sumamente importante en este sentido 
el texto La catedral y el bazar de Eric. S. Ra-
ymond (1999), hacker conocido y respeta-
do por la comunidad informática mundial.
37
Documento	fundacional	de	la	free	software	fundation:
<http://www.gnu.org/gnu/initial-announcement.html>
Cuando hablamos de software libre nos referimos a 
cualquier aplicación sobre la cual uno puede tener 
acceso al código fuente. En ese sentido existen una 
diversidad de licencias de uso que determinan qué 
puedo y qué no puedo hacer con ese software. Funda-
mentalmente la cuestión se encuentra dividida en tres 
grandes problemas: si puedo o no distribuir mi aplica-
ción y/o cómo puedo hacerlo, si puedo o no modificar 
el código mejorándolo o adaptándolo a mis propias 
necesidades y/o cómo puedo hacerlo, y si distribuyo 
comercialmente copias de ese software o modifico el 
código original, cuáles son las condiciones que se apli-
can sobre mi acción.
Sitio	oficial	de	Eric	Raymond.	
<http://www.catb.org/esr/>
Es nuestra intención promover el uso de software libre en todo lo que sea posible puesto que nos parece relevante en 
términos educativos poder contar con la posibilidad de explorar cómo se programaron ciertas herramientas que uti-
lizaremos a lo largo de este material. También nos parece importante contar con la posibilidad de exponer y distribuir 
nuestro trabajo de manera libre y cooperativa; sin mayores restricciones.
Es en ese sentido que nuestro recorrido estará centrado en dos aplicaciones, en un amplio sentido, fundacionales de 
nuestra disciplina. Nos referimos a los softwares PD (Puredata) y Processing.
<www.puredata.info>
38
2.3. Herramientas de software
2.3.1. Pure data (PD)
Pure Data (aka Pd, luego devenido max/MSP) es un lenguaje de programación 
visual de fuente abierta. PD permite a los músicos, artistas visuales, bailarines y 
coreógrafos, investigadores y desarrolladores de software crear gráficamente, sin 
necesidad de escribir líneas de código. PD se utiliza para procesar y generar soni-
do, video, gráficos 2D/3D, sensores de interfaz, dispositivos de entrada y MIDI. PD 
es adecuado para el aprendizaje de los procesamientos multimedia básicos y mé-
todos de programación visual, así también como herramienta de prototipado de 
sistemas más complejos para proyectos de gran escala. (www.puredata.info)
Imágen 2.1. Captura de la web de puredata
Fuente: www.puredata.info
Si bien PD permite generar, controlar y producir imagen en movimiento, será nuestra herramienta preferida para todo 
lo que tenga que ver con control y procesamiento de sonido ya que es allí donde encontramos sus mayores virtudes.
PD es un lenguaje de programación que utiliza una metáfora gráfica 
para construir los bloques funcionales. A este tipo de paradigma se lo 
conoce como “programación visual” o “programación por flujo de da-
tos”. Al respecto puede consultarse <http://en.wikipedia.org/wiki/Data-
flow_programming> (en Inglés)
39
PD se encuentra disponible en varios “sabores”. En particular, vamos a instalar la última versión que aparece dispo-
nible en la web de Pure Data. La versión que utilizaremos es la que aparece definida como “pd-extended”. Incluye el 
núcleo de la aplicación creado originalmente por Miller Pucket más una serie de adicionales que nos permiten una 
mayor cantidad de utilidades.
Enlace	para	la	descarga	del	programa:	
<http://puredata.info/downloads/pd-extended>
Imágen 2.2. Captura de la página de descarga
Fuente: www.puredata.info
Una vez instalado, al iniciar, el programa PD nos ofrece la ventana de terminal. Esta ventana es nuestra puerta de co-
municación con el programa. Todos los lenguajes de programación ofrecen algún medio de entrada y salida de datos. 
En este caso, la consola de PD nos muestra información relacionada con el estado actual de la aplicación y de nuestro 
programa (de ahora en adelante patch).
Tutorial/Manual sobre PD, completo y en castellano. Constituye una de 
las mejores referencias en español disponibles en la web:
<http://www.lucarda.com.ar/pd-tutorial/>
Processing no es el primer ejemplo de lenguaje para producir imáge-
nes. DBN (Design by Numbers) es una aplicación/lenguaje creado por 
un docente del MIT, John Maedea, quien fue profesor de Reas y Fry. En 
cierto sentido Processing puede ser considerado como la evolución de 
DBN, tal cual quedó registrado en la última actualización del sitio en 
2003. <http://dbn.media.mit.edu/>
40
Imágen 2.3. En la consola de PD podemos ver cómo está funcionando la aplicación 
y recibir información sobre la ejecución de nuestro patch.
Fuente: elaboración propia.
2.3.2. Processing
Processing es a la vez un lenguaje de programación (un API), un entorno y una comunidad de desarrollo de software. 
El proyecto fue originado por dos estudiantes del MIT como proyecto de tesis. La propuesta era construir un sistema 
informático para que los alumnos o estudiantes de artes visuales, pudiesen, a la vez que aprenden a programar, cons-
truir imágenes de manera programática.
La fascinación de Casey Reas, uno de los mentores del proyecto, tenía que ver con la posibilidad de aplicar procesos 
algorítmicos para la generación de dibujos. Su intención era la de generar dibujos automáticamente.
Si bien esta idea está presente desde hace muchísimo tiempo, no fue hasta el lanzamiento de Processing que el recur-
so informático se empezó a usar de manera casi ubicua en el arte visual digital.
 
En gran parte, el éxito de Processing se debe al trabajo de Ben Fry (el otro integrante de la dupla) de perfil más técni-
co. Fue Fry quien logró desarrollar un sistema basado en java que permitiese