Explorando la red: OSC

Open Sound Control (OSC) fue inventado en 1997 por Adrian Fred y Matt Wright para el centro de nuevas tecnologías de música y audio (the Center for new music and audio technologies CNMAT, por sus siglas en ingles). Resulta evidente, con solo leer el nombre, que al igual que MIDI fue una tecnología diseñada para la industria del audio.
Se diseñó como medio de comunicación y optimización de redes entre ordenadores, sintetizadores de sonido y otros dispositivos multimedia. Sobra decir, que OSC ha recorrido un largo camino desde 1997. Actualmente, tras la última revisión de las especificaciones, siendo 1.1 en 2009, el protocolo ha sido implementado en diferentes sectores y tiene múltiples usos como la robótica, el servicio web, el vídeo y por supuesto el control de iluminación. Algunos proponen un cambio de nombre por uno que refleje más su utilidad, como el sugerido en el NIME 2009 Paper: “Open System control” pero tras tanto tiempo bajo el nombre de “Open Sound Control” su cambio llevará un tiempo.
OSC es un formato de contenidos, también conocido como un protocolo, en el que se define el formato del mensaje. En resumen, OSC no define la semántica lingüística del mensaje, sino que indica cómo debería componerse el mensaje. Lo que significa, que a diferencia de los protocolos como MIDI Show Control, donde un comando “ir” es universalmente entendido y estandarizado en los diferentes dispositivos, en OSC el mensaje puede ser compuesto, y normalmente lo es, de diferentes normas. No hay una estructura de contenidos predeterminada, lo que le da una gran flexibilidad, permitiendo así a los fabricantes publicar sus propios diccionarios y a los usuarios a conectar diferentes mecanismos y aplicaciones. Enviando señales, moviendo faders, recopilando y cambiando información de uno a otro. OSC es una pequeña joya.
Utilizando una analogía pobre, OSC se podría comparar con el modo convencional de escribir una postal. Con la dirección del destinatario en la parte superior derecha, nuestro mensaje empezaría con “Querido…” en la parte izquierda y finalmente firmando con nuestro nombre y un par de besos al pie del papel. OSC nos indica como escribir la postal, pero no nos dicta el contenido. OSC tiene múltiples ventajas ya que, si nos alejamos de la analogía de la postal, mejora en el ámbito de la organización y la documentación, permitiendo a los fabricantes crear diccionarios para que los usuarios puedan obtener información de sistemas complejos.
Cabe mencionar que OSC está clasificado como layer 6 o Presentation Layer entity. Lo que quiere decir que es una vía independiente. Volviendo a la analogía de la postal, OSC nos indica la forma en la que deberíamos de escribir el mensaje, pero no nos establece la forma en la que debe ser enviado. En este artículo discutiremos sobre la cualidad de formato de contenido de OSC, pero no te alarmes, también discutiremos el uso de OSC en los diferentes protocolos de envío de la información.

OSC messages
El formato de los mensajes OSC se puede dividir en tres partes: Address Pattern, Type Tag y los argumentos de los que van seguidos.

  • El Addres Pattern o patrón de dirección, es un código único de patrones encriptados en UTF-8, que comienzan con el carácter “/” (barra lateral) ej: “/eos/cue/1/0.5/fire.” A veces denominado como namespace, suele escribirse entre Barras laterales, al igual que las URLs, donde la estructura del sistema o de los dispositivos funcionan correctamente, y donde los parámetros se ubican en torno a un árbol jerárquico, al que podemos llamar “address space.” El Address Pattern es simplemente un camino desde el árbol jerárquico hasta el nodo.

mensaje

  • La Type Tag es una cadena de caracteres que comienzan siempre con el carácter “,” (coma) seguido de una secuencia de caracteres que corresponden exactamente a la secuencia de argumentos del mensaje ej: “,ifsbt” Todos los caracteres situados detrás de la coma se denominan OSC Type Tag y representan el modelo de datos del argumento correspondiente.
 OSC Type         Tag Data Types Examples
          i           Integer 18, 79, 21
          f           Float 3.8, 0.4, 36.9
          s           String King Kong, Eos Console, Hello World
          b     Blob (aka a byte                  array) 01001010 01011111 01001011 10111000
          t           Time Tag  An OSC Timetag encoded in NTP Format

Por otro lado, el argumento puede no estar asociado a ningún Byte, por lo que el type tag correspondiente se usará para definir el significado.

 OSC Type            Tag Meaning
          T TRUE
          F FALSE
         N Null (aka nil, none)
          I Impulse (aka “bang”), used for triggers. This type was named “infinitum” in OSC 1.0

primero

Para un uso adecuado de OSC, no es necesario el conocimiento de OSC Type Tag, ya generalmente se utiliza para distinguir que tipo de información va a ser leída, y para encontrar algunos errores de verificación.

  • Los argumentos. Cada mensaje de OSC puede tener tanto múltiples argumentos como ninguno. En la mayoría de los casos, los desarrolladores usan el patrón de dirección para documentarse y describir la información dentro de los argumentos que deben seguirse.

 Example 1:

Address Pattern = “/time/out/hoursPerDay”

OSC Type Tag String = “,i”

Arguments (1) =  “24”

Example 2:

Address Pattern = “/cue/{cue number}/colorName”

OSC Type Tag String = “,s”

Arguments (1) =  “green”

Example 3:

Para extraer la información de la señal (cue) de las consolas Eos family de ETC, se manda un mensaje con un “address pattern” ““/eos/get/cue/{cue list number}/{cue number}.” que a su vez devolverá el mensaje OSC.

Address Pattern = “/eos/out/get/cue/{cue list number}/{cue number}”

OSC Type Tag String = “,issiiii…”

Arguments (27) =

1 <- Index

B0BAW0A0-3BBE-888B-F61CA125D0B0 <- OSC UID

Houselights Out <- Label

3 <- Up Time

5 <- Down Time

0 <- Up Time Delay

0 <- Down Time Delay

segundo

OSC Bundles
Un Bundle o paquete es una secuencia de mensajes, que permite la agrupación de mensajes OSC en un mismo paquete que será procesado automáticamente por la aplicación; en otras palabras, es como si todos los mensajes agrupados en un bundle fueran procesados al mismo tiempo.
Todos los bundles tienen su propio timetag o etiqueta de tiempo, que especifica el momento en el que todos los mensajes del paquete deben de ser procesados. Habréis notado que se puede añadir un argumento al mensaje OSC como etiqueta de tiempo, permitiendo programar el tiempo exacto de la ejecución del mensaje, lo que nos permite predefinir una secuencia de eventos.
Los bundles OSC ofrecen la opción de ser minucioso con el address pattern del mensaje, permitiendo la descripción de atributos individuales a los elementos de un bundle, pero consintiendo a la aplicación que los trate como si fueran uno solo, unificándolos y procesándolos juntos como paquete.
Por ejemplo, un bundle OSC podría estar formado por dos mensajes OSC:

OSC Message 1:

Address Pattern = “/fixture/1/pan”

OSC Type Tag String = “,f”

Arguments (1) =  “270.0”

OSC Message 2:

Address Pattern = “/fixture/1/tilt”

OSC Type Tag String = “,f”

Arguments (1) =  “14.6”

En este ejemplo se describen los atributos de inclinación del primer elemento. Mandando dos mensajes OSC en un mismo paquete, cada uno con un Address pattern que describe claramente su argumento y evita la confusión.
Sin embargo, la misma información del primer elemento podría ser enviada como un mensaje OSC individual, pero podría crear confusión en cuanto a qué argumento acompañante se refiere a qué atributo.

OSC Message:

Address Pattern = “/fixture/1/focus”

OSC Type Tag String = “,ff”

Arguments (1) =  “270.0”

Arguments (1) =  “14.6”

Conclusión
En resumen, nos encontramos ante un “protocolo” que nos ofrece un esquema de direccionamiento creativo, intuitivo y extenso. O por decirlo de otro modo, ante un diccionario de comandos que permite interactuar al usuario con los dispositivos para llevar a cabo acciones o solicitar información de ellos. Con solo echar un vistazo a los diccionarios de las familias de Eos Cobalt y de Eos ColorSource, se puede observar la cantidad de información que puede ser extraída y todas las acciones posibles. Esto permite a los usuarios crear y usar aplicaciones que puedan actuar como remotos para ver e interactuar con las plataformas, personalizar la documentación de los montajes archivados, sin mencionar la capacidad de crear increíbles shows interactivos.

Seguramente te estarás preguntando “¿Cómo puedo utilizar este Protocolo?” Bueno, mantente al loro ya que no hemos hecho más empezar con un pequeño resumen del protocolo. En el resto de las series, vamos a explorar como implementarlo.

ultimo

  • Más adelante publicaremos más artículos relacionados.
Scroll al inicio