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 dispositivo), output (salida). En términos prácticos se refiere 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 computadoras 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érminos 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, terremotos, 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.

 

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 motorizados”, “generadores de viento”, etc. En general, nos limitaremos a artefactos capaces de producir sonido o imagen (proyectores, pantallas, sistemas de sonido, etcétera).

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.

 

 

 

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 relació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 el caso de los sistemas informáticos, esta interfaz puede dividirse en dos espacios, el de los dispositivos comúnmente 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 (producidas 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, electromagné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 problema del orden virtual, ya que su problemática es casi estrictamente algorítmica. Realizar una detección de movimiento por medios ópticos se encuentra relacionado con ambos aspectos ya que, por un lado se debe obtener 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.

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 multimedial 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 representan magnitudes del orden de lo físico, lo verdaderamente importante del asunto es poder relacionar esos parámetros 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á preproducido. 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.

Infinidad de dispositivos controladores salieron al mercado en los últimos años: perillas, botones, teclados 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 tradicionales 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.

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 aparejadas 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 pensados 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 modelos 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.

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 software 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 desarrollo específicos para diseño y producción de arte visual y sonoro. Y en el otro extremo tendremos softwares prediseñados, 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 responde a los tipos de aplicaciones que consideramos más relevantes para nuestra disciplina. A lo largo del material intentaremos describirlos:

 

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.

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.

También encontramos lenguajes de programación para contenidos multimediales que nos permitirán construir nuestras propias herramientas con funciones particulares. Estos lenguajes de programación permiten que el usuario defina (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 visuales 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 funcionamiento 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.

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 cables, 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.

 

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 artistas 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 programado. 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 desencadenando bajo 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 microelectrónica. La plataforma de hardware libre Arduino es otro ejemplo de ello.

 

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.

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 resuelve 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 comunicarse con una cámara web sin necesidad de saber específicamente nada sobre la cámara. Otras librerías están destinadas 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 desarrolladores 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.

 

Como referencia a otros lenguajes de programación y entornos para la computación gráfica interactiva mencionaremos solo dos:

openFrameworks: aparece como una alternativa a Processing para aquellos realizadores que además poseen un conocimiento más avanzado en programación o que ya hicieron sus primeros pasos en Processing y ahora sus aplicaciones 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ódigo 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 interactú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

 

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.

 

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.

 

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 interfaces o dispositivos.

La comunidad de software libre trabaja con ese tipo de software por lo tanto es 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 sistemas GNU/Linux en gran cantidad de dispositivos multimedias como RaspberriPI y otros.

 

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.

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 algoritmo 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.

 

 

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 creadas 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.

 

 

El siguiente video muestra las imágenes de las pantallas sensibles al tacto multitacto hechas por Jefferson Han.

 

 

 

 

 

 

 

1.2.8. Protocolos de comunicación

Dada la gran complejidad de las tareas que un sistema interactivo debe contemplar para poder generar una experiencia 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 conjunto, 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.

 

Esta idea es tomada luego por los fabricantes de instrumentos musicales digitales para desarrollar la norma de comunicació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 fabricantes 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 (compartir 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 conexió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 representa valores de entre 0 y 127. La combinatoria de varias de estas “palabras” se establece 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 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 transferencia 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 computadoras 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.

 

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 especificació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 microcontroladores 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 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 importante, puertos de entrada y salida digitales y analógicos.

Estos puertos nos permiten conectar Arduino con casi cualquier otro dispositivo electrónico (generalmente por medio 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 controlar algo externo) o como entradas en el caso de que necesitemos utilizar sensores. Arduino (la comunidad y el proyecto en sí) prevé este tipo de usos por lo cual la extensa documentación en su web hace en gran parte su existencia.