Entrevista a Emiliano Causa (proyecto Biopus)

Entrevista Emiliano Causa

http://www.biopus.com.ar/

por Lila Pagola
julio 2010

- Usás herramientas de software libre en muchas de tus obras. ¿podrías desarrollar cómo y por qué llegaste a ellas?

En el trabajo con el grupo Proyecto Biopus, a las herramientas open source las fuimos conociendo al mismo tiempo que nos fuimos adentrando en el software para el control de sonido y video en tiempo-real. Cuando empezamos a explorar las primeros herramientas y lenguajes de programación para hacer instalaciones interactivas, nos encontramos con que de los ocho que conocíamos en ese momento, salvo dos, todos eran open source. La cuestión era clara: nuestro desarrollo y búsqueda estaba enmarcado en el campo de la investigación académica que era de donde surgían estas herramientas. Vimos que estas herramientas provenían de investigaciones y gente que tiene como objetivo la producción de conocimiento, más que el rédito económico. Un ejemplo claro era EyesWeb que estaba desarrollado por el laboratorio Infomus de la Universidad de Génova o Processing, inicialmente desarrollado en el MIT y la UCLA. Tiene cierto sentido si uno piensa que Proyecto Biopus surgió dentro del ámbito universitario, ya que si bien no estuvimos ni estamos amparado por ninguna universidad, nos conocimos y trabajamos (individualmente) en la universidad.

- En el texto “Software Open Source y el desarrollo de Nuevas Interfaces en el Arte Interactivo”1(2006) se enfatiza el hecho de que las alternativas open source son gratuitas. Sin embargo, todos sabemos que en general conseguir licencias “no autorizadas” no suele ser un problema en Argentina. ¿dónde ubicarías hoy la principal diferencia, especialmente desde el punto de vista docente, osea, como herramienta para aprender?

Las herramientas Open Source pertenecen a una revolución hacker que se describe muy bien en el libro “La ética hacker y el espíritu de la era de la información”2, de Pekka Himanen, libro que recomiendo mucho. Es decir, va más allá de la gratuidad de la herramienta. La diferencia principal entre el software con Licencia y el Open Source, es que mientras que el primero tiene un fin principalmente económico, el segundo está movido por la investigación y la producción de conocimiento. Estos fines a veces pueden ir de la mano, pero a veces se contraponen. Por ejemplo: en el software Open Source el versionado es constante, yo empecé a trabajar con la versión 068 de Processing y al cabo de 4 años avanzó hasta la 138 luego de la cual pasó a ser la 1.0.0 y hoy anda por la 1.2.0; esto quiere decir que cada pequeño cambio, cada arreglo nuevo aparece en una nueva versión en cuestión de días. Esto es imposible en el software con Licencia paga, ya que las estrategias de mercadeo no lo permiten, si se encuentran errores habrá que esperara años para subsanarlos.

Las herramientas Open Source están soportado por una inmensa comunidad que las hace crecer constantemente, Processing tiene una gran cantidad de “librerías” hechas por otras personas que extienden el lenguaje, lo que lo hace cada vez más potente. Esa comunidad también sirve para asistir a las personas que utilizan las herramientas, a través de foros (por ejemplo) y el usuario se siente más integrado en un proceso de investigación y desarrollo, ya que es común que uno termine siendo el que testea el lenguaje.

Es cierto que es sencillo conseguir Licencias pagas en forma “no autorizada”, es decir gratuitamente, pero esto es una práctica que linda con la ilegalidad. En los países periféricos, como el nuestro, la gente no tiene el poder adquisitivo necesario para poder comprar herramientas de software con Licencia, esto nos obligó a muchos de los artistas que trabajamos en arte con nuevas tecnologías (particularmente con tecnologías informáticas) a utilizar herramientas en forma “ilegal” durante los primeros años. A mi no me gusta sentir que le estoy robando nada a nadie, y en ese sentido las herramientas Open Source (de licencia libre) me han permitido trabajar con software de primera en forma totalmente legal, para mí éste no es un tema menor ya que implica que el factor económico no es un factor de exclusión en nuestra práctica, aunque esa exclusión en los primeros años no estuviera dada en lo efectivo pero sí en el imaginario de la legalidad.

- Actualmente trabajás con Processing, en el mismo texto anterior mencionaban a Max, en otro momento usaron Shockwave. ¿Reconocés características de las herramientas en las producciones (marcas de estilo si se quiere, una suerte de sintaxis), que puedan asociarse a la imposibilidad de escapar de ciertos resultados?

Desde hace unos cuantos años trabajamos con Processing, y durante mucho tiempo hemos trabajado en MAX pero hemos migrado a Pure Data (que es el mismo tipo de software pero versión Open Source) por el tema de las licencias. Shockwave lo utilizamos hace muchos años y quedó en nuestro sitio por que no hemos actualizado esos trabajos.

Yo distingo entre dos tipos de lenguajes de programación, 1) los que lo hacen por código: como Processing y OpenFrameworks, y 2) los que lo hacen con entornos gráficos de objetos: como MAX, Pure Data, EyesWeb, VVVV y Quark Composer, entre otros. A mí en particular me gusta más el primer tipo, ya que este tipo de lenguajes te ofrece “un papel en blanco” en donde uno tiene que construir todo desde cero, es un procesos muy arduo pero de libertad casi total. Mucho tiempo utilicé EyesWeb, el cual es muy potente para procesar imagen en tiempo-real, pero en un momento empecé a notar que los objetos preconfigurados que trae estaban limitando mis posibilidades, de alguna forma los lenguajes como EyesWeb y VVVV pueden terminar determinando una cierta estética, ya que las posibles operaciones que permiten sus objetos, tiende a privilegiar ciertos procesos por sobre otros. En líneas generales, esto sucede con cualquier lenguaje de programación, pero en el caso de los entornos gráficos se hace más agudo. De todos modos, en nuestra práctica, nadie puede utilizar sólo una herramienta, lo más común es utilizar varios lenguajes a la vez y conectarlos entre sí. En nuestro caso, es común que usemos Processing vinculado con Pure Data vía MIDI o por protocolo de Red. La forma de escapar de esta suerte de estética “determinada” por el lenguaje es mezclarlos y tener una suerte de “paleta” de estéticas y posibilidades (dadas por los lenguajes).

- ¿qué relación podés establecer entre la participación del receptor que requieren tus producciones, en tanto lúdicas, y el tipo de usuario “proactivo”, curioso, que requiere -por el momento- el software libre?

Creo que en ambos fenómenos se encuentra la necesidad y la toma de posición de “participar en el proceso”. En el caso del público en nuestras obras, participa en la construcción del discurso, en trabajos como “Sensible3“, si el público no participa no hay obra, nada sucede. Siempre digo que nosotros no construimos el discurso en sí, sino que construimos la gramática con la que el público construye su lenguaje. Nuestros trabajos no intentan ser objetos de arte, sino procesos de arte, procesos que se desencadenan a partir de la participación. Creo que en el software libre, el usuario es partícipe de un proceso de investigación a través del testeo, la participación en los foros y otras actividades que implican las comunidades involucradas con este tipo de software. Creo que una de la frases del momento es el “do it yoursef” (DIY: hágalo ud. mismo) que nos invita a apropiarnos de los procesos y construir nosotros mismos, por ejemplo, aparatos, como se ve en el fenómeno del hardware hacking, circuit bending, que no es otra cosa que la ética hacker de software abierto traspasada al hardware. Por esto es que creo que es tan sencillo establecer cierta hermandad entre la ética hacker y el arte electrónico.

- Algunas de las obras en Biopus tienen el código fuente abierto, otras no. ¿podés comentarme cómo toman esas decisiones, o si son resultado del azar/la disponibilidad de tiempo, y qué reflexión te generan?

Nuestra idea, en principio, es que todas lo tengan, pero en general tratamos de que el código publicado tenga una función pedagógica, es decir, que esté presentado de forma tal que la gente lo pueda interpretar y utilizar. Con las instalaciones interactivas, esto nos resulta más difícil por que la cantidad de código existente en estos trabajos es muy extensa e involucra a más de un lenguaje y/o aplicaciones. La cantidad de horas de trabajo, en estas obras, nos ha obligado a no ser tan prolijos en la elaboración del código, como a nosotros nos gustaría, y ciertamente no nos gusta publicar el código en ese estado. Es una suerte de “pudor” informático, por decirle de alguna forma. Siempre tenemos la intención de hacer una síntesis digerible de esos códigos y publicarlos, la verdad es que el tiempo y las urgencias nos ganan. Pero en el caso de Sensible, la mayor parte del código, en realidad está publicado en el Tutorial de Vida Artificial para el Arte4 (aunque esta relación no esté explicitada en el sitio) y nuestra idea es convertir los algoritmos para la pantalla sensible al tacto (hechos por nosotros) en una herramienta “Open Source” de libre distribución, es un proyecto que venimos trabajando muy lentamente.

- En el sitio hay además alguna obra en Shockwave, más dificil de ver en el presente. ¿Tenés alguna reflexión sobre los formatos de archivo, su portabilidad e interoperabilidad en relación nuevamente, a las propuestas de los formatos abiertos http://www.openformats.org/es)? ¿cómo te parece que afectan  estas cuestiones en particular a las producciones artísticas, en nuestro contexto específico (con su política cultural, de conservación, etc.)?

Si yo pudiera elegir y tuviera el tiempo suficiente, migraría todos esos trabajos a tecnologías abiertas. La verdad es que en el sitio de Biopus se ve el paso de la historia del arte con tecnología en Argentina (sin intención de ser pretencioso en ésto), es decir, se ve la huella del pasaje de las tecnologías propietarias a las tecnologías abiertas. Los primeros trabajos estaban hechos en Visual Basic, Director, Flash, hoy en día todos están hechos con tecnologías “Open Source”: Processing, Pure Data, VVVV, EyesWeb. Con la disponibilidad de tiempo actual, tenemos que elegir entre migrar esos trabajos, o hacer nuevos, o sino, despublicarlos. Frente a esto, preferimos dejar la historia tal como fue y seguir trabajando en lo nuevo.

En el 2008 participamos de un encuentro sobre Conservación del Arte Electrónico, durante este encuentro expusimos una serie de factores que dificultan (y a veces imposibilitan) la conservación de una obra electrónica y/o digital:
Software:

  1. Obsolescencia y discontinuación del software
  2. Posibles incompatibilidades entre hardware y software en las futuras actualizaciones o migraciones de sistema
  3. Durabilidad y compatibilidad del soporte de almacenamiento y backup

Hardware:

4) Deterioro y obsolescencia del hardware informático, de los dispositivos físicos de sensado y actuación (e/s) del sistema.

5) Deterioro físico de los componentes escenográficos

Montaje:

6) Adecuación y legibilidad de las instrucciones (instructivos) de montaje, instalación, puesta en marcha y calibración.

7) El guionado de la actividad del performer (en el caso de las performances).

(tomado del texto “De como preservar lo vivo en el arte interactivo”5 del grupo Proyecto Biopus)

El formato en el que se publica y distribuye un trabajo de arte electrónico entra principalmente en el punto 1 de los aspectos detallados arriba, en donde un formato cerrado, corre el riesgo de ser discontinuado y debido a su hermetismo dificultar su migración a un nuevo formato. Creo que todos lo factores enumerados arriba son un serio inconveniente para la conservación del arte electrónico, es difícil pensar en conservar una obra de este tipo de acá a 20 años (por ejemplo).

Notas:

1http://liminar.com.ar/simposio/pdf/biopus.pdf

2www.tallerh.com.ar/sitio/textos/hack.pdf

3http://www.biopus.com.ar/sensible2/index.html

4http://www.biopus.com.ar/emiliano/tutorial_vida_artificial/index.html

5http://www.biopus.com.ar/textos/De_como_preservar_lo_vivo.pdf

Artículos relacionados

Entrevista a Leonardo Solaas [pre ISEA 2010]

Con esta entrada inicio la publicación de una serie de entevistas que hice el mes pasado, para la presentación que estoy preparando sobre artistas que usan software libre en Argentina (y Uruguay incluso). La charla tendrá lugar en ISEA (International Symposium on Electronic Art), en Dortmund, Alemania, a fines de agosto.

Estas entrevistas vienen a ser como el “código fuente” de mi texto, que publicaré al final.
Acá la primera entonces, la charla que mantuvimos con Leonardo Solaas [http://solaas.com.ar/]

Leonardo Solaas

http://solaas.com.ar/

Entrevista por Lila Pagola
julio 2010

- Analizando tu trabajo, vos has trabajado indistintamente con software libre o con software privativo, por lo que tu relación con las herramientas de software parece ser más instrumental que de otro tipo. ¿estoy en lo correcto?

Tu apreciación es correcta, mi elección de herramienta siempre está guiada por consideraciones prácticas: en cada caso elijo la que me parece más apropiada para el contexto y los problemas técnicos que plantea un trabajo particular.

Una excepción a ese pragmatismo es mi práctica docente. Todos los ejemplos de sistemas generativos que hago para los alumnos están programados en Processing – no sólo porque es una plataforma de fácil acceso y orientada a lo didáctico, sino porque me parecería absurdo ponerlos en la situación de comprar o piratear un entorno de desarrollo propietario habiendo alternativas libres.

- Me gustaría que me comentes, en los casos que usás software libre, cómo has llegado a él, cómo aprendiste, que resultados/diferencias encontrás con el software privativo, y especialmente, si te has relacionado con la comunidad de usuarios de ese software, y como ha resultado esa experiencia.

Mi “caja de herramientas” habitual está formada por tres plataformas, de las cuales dos son de fuente abierta: Flash / ActionScript 3.0, Processing / Java, y Drupal / PHP-MySQL. Además también uso formatos y protocolos basados en estándares abiertos, como HTML, XML, JavaScript, etc.

Mis primeros pasos autodidactas en la programación vinieron, como le sucedió a mucha gente, en el entorno Flash, cuando dejé de usarlo exclusivamente como herramienta de dibujo y animación y me animé a poner unas líneas de código aquí y allá. Apenas le tomé el gusto a la programación descubrí la alternativa del Processing, que me ofrecía algunas posibilidades diferentes, en especial un entorno completamente orientado al código y una performance muy superior para trabajar con grandes cantidades de objetos.

Por otro lado, Flash tenía y sigue teniendo sus propias ventajas, de las cuales la principal es, diría yo, de usabilidad y continuidad de la experiencia de navegación en la web, que es un problema que los applets de Java por desgracia nunca han terminado de resolver bien. A eso se suman cuestiones técnicas como la calidad de renderización de texto, la facilidad de construir interfaces de usuario, etc.

Paralelamente empecé a hacer sitios, estáticos al principio, pero muy rápidamente tuve la necesidad de volverlos dinámicos. Aprendí algo de PHP y MySQL, y tuve una experiencia breve y complicada con Mambo/Joomla. Después descubrí Drupal, que me parece un ejemplo excelente de desarrollo open source sólido y poderoso. Lo uso desde hace años cada vez que necesito un sistema de administración de contenidos. En esta área, por algún motivo misterioso, ni siquiera existen alternativas propietarias relevantes. Supongo que un sistema modular y de propósito amplio como estos se presta especialmente bien al desarrollo colaborativo.

Mi relación con la comunidad de Processing se ha limitado a algunas participaciones en los foros. En cambio, estuve mucho más implicado con la de Drupal. Soy el fundador del grupo Drupal Argentina (http://groups.drupal.org/argentina), actividad que se extendió en varios encuentros presenciales con otros usuarios de Buenos Aires. También he contribuido un módulo al ecosistema. Ahora mi trabajo ha tomado un giro que me lleva hacia otros rumbos, así que mi participación en la comunidad ha disminuido.

- Por otro lado, quisiera que me cuentes si te has planteado la cuestión de abrir el código de tus desarrollos, ya sean con SL o no. No veo ejemplos en el sitio, pero quizá los tengas, aunque en realidad lo que me interesa es saber que opinás al respecto, en relación al arte principalmente pero también a otros ámbitos en los que trabajás.

No tengo un hábito sistemático de compartir el código, pero eso tiene más que ver con la falta de tiempo para limpiar las cosas y publicarlas que con la falta de ganas de hacerlo. Es el mismo motivo por el que pongo noticias nuevas en mi blog con muchísima menos frecuencia de lo que desearía. Supongo que es un mal común de la era digital…

Sin embargo, cada tanto lo hago, ya sea con algún experimento como éste: http://solaas.com.ar/node/15 o con trabajos más grandes, como Dreamlines: http://solaas.com.ar/dreamlines/p5/ y por supuesto en mi tarea docente, que me da la excusa para ser más sistemático: http://solaas.com.ar/generativos/ejemplos.html

Mi postura general con relación al tema es que cualquier cosa que se pueda codificar digitalmente, desde un algoritmo a un tema musical, se puede transmitir y reproducir con un costo casi nulo, que esa es una realidad “material” que traen consigo las nuevas tecnologías, y que cualquier intento por restringir o controlar esa realidad está de antemano condenada al fracaso. Yo he aprendido muchísimo de diversas fuentes de código abierto, y trato de contribuir a la expansión de ese conocimiento. Creo que el punto de aplicación más claro de esa postura es la docencia, que en los últimos dos años va tomando más espacio en mi vida y que disfruto mucho. Soy profesor de la Maestría en Artes Electrónicas de la UNTREF (Universidad Nacional Tres de febrero) y doy talleres en el CCEBA (Centro cultural de España en Buenos Aires).

Dicho esto, en la comunidad del software libre veo a veces posiciones que me parecen un tanto maníqueas y fundamentalistas, y con las cuales no me identifico. Creo que el proceso de expansión de la información y el acceso a herramientas digitales depende de un ecosistema muy complejo con distintos tipos de actores. Por ejemplo, los flujos de personas, código y dinero entre iniciativas open source y corporaciones es cada vez más intenso, y muchas veces productivo para todos. Yo mismo me gano la vida trabajando para empresas del primer mundo, y eso me permite desarrollar un arte que, como en el caso de Outsource Me!1, puede incluso ser crítico o reflexivo acerca de esa misma relación.

Por supuesto que políticas absolutamente excluyentes y cerradas, como lo que Apple está implementando con el IPhone, me resultan muy antipáticas, pero creo que aún eso tiene un lugar como punto de entrada a la tecnología para gente que de otro modo quedaría afuera. Y no hay que olvidarse que la alternativa abierta, mucho más “simpática”, que es Android, también está después de todo respaldada por una gigantesca corporación.

También creo en la apropiación de los medios de producción por medios tales como la piratería y el hacking. Diría en resumen que la mía es una actitud más bien hacker, de tomar lo que me sirve mejor y usarlo, buscando el mínimo de esfuerzo y la máxima productividad, que me interesan principalmente las ideas que quiero llevar a cabo y no tanto las herramientas, a las que presto la atención estrictamente necesaria para alcanzar mis objetivos.

Artículos relacionados