O OSC (OpenSound Control)1 é um protocolo desenvolvido pelo CNMAT (Center for New Music and Audio
Technology) da Universidade de Berkeley, Califórnia e, à semelhança do protocolo MIDI, tem como
propósito possibilitar a comunicação entre computadores, sintetizadores, e outros dispositivos multimédia. A especificação deste protocolo – OpenSound Control Specification 1.0 [50] – foi redigida em 2002 e, sendo cerca de 20 anos mais recente que o MIDI, revela-se mais apropriado às necessidades actuais, nomeadamente, na utilização de redes de comunicação modernas para a transferência de dados, e na definição de uma linguagem com maior abertura e maior resolução do que a utilizada no protocolo MIDI.
2.3.1 Resumo das características do OSC
A arquitectura do OSC é baseada no conceito de cliente / servidor, sendo que qualquer dispositivo que envie pacotes é considerado cliente e qualquer outro que os receba, será considerado servidor. Um dispositivo poderá ser considerado cliente e servidor simultaneamente. O OSC é um protocolo completamente independente da tecnologia física de transporte da informação. Desta forma, torna-se extremamente versátil, podendo-se integrar em praticamente qualquer tecnologia de rede.
No OSC, o método de atribuição de nomes às mensagens é feito de forma dinâmica e aberta, com uma estrutura semelhante à de um URL (ex: “oscilador/4/freq”). São suportados vários tipos de argumentos para as mensagens: strings ASCII, ints e floats de 32 bit, 64 bit, entre outros. Este protocolo incorpora um sistema de pergunta (queries) para conhecer as capacidades de outro dispositivo OSC de uma forma dinâmica. Possibilita ainda a utilização de funções de Pattern Matching (“?”, “*”, “[ ]”, etc.) com utilização similar à de uma shell em UNIX, permitindo assim a especificação de múltiplos destinos para uma única mensagem.
Em termos de gestão temporal, a inclusão de Time Tags permite uma alta precisão temporal (abaixo do nano- segundo), utilizando o mesmo formato do protocolo Internet Network Time Protocol (NTP). Contempla ainda a possibilidade do envio de Bundles de mensagens (com um time tag associado), cuja acção deva ocorrer simultaneamente.
1
2.3.2 Arquitectura de Rede do OSC
Em termos de arquitectura de rede, os equipamentos ou os diversos componentes de software que utilizam o OSC podem comunicar através de várias formas:
• Multiprocessamento distribuído em LANs (cooperação para atingir uma única tarefa) • LANs ou WANs Peer-to-peer (comunicação entre dispositivos, mas operação independente)
• Máquina isolada (várias aplicações, plugins ou processos residentes na mesma máquina comunicam internamente por OSC).
No contexto da arquitectura protocolar TCP/IP, o OSC encontra-se ao nível da aplicação, utilizando o UDP (User Datagram Protocol) como protocolo ao nível do transporte. Contudo, não existe nenhuma obrigatoriedade em utilizar o UDP; é também possível utilizá-lo com o protocolo TCP. A utilização do protocolo UDP como forma de transporte preferencial no OSC prende-se com o facto de este não estabelecer ligação nem incluir métodos de confirmação da recepção dos datagramas [51]. O UDP é por isso mais utilizado por razões óbvias de rapidez de resposta, visto ser, como o MIDI, um protocolo de comunicação vocacionado para o controlo de equipamentos e de software em tempo-real. Neste contexto, a baixa latência proporcionada pelo UDP será mais importante do que a fiabilidade garantida pelo TCP mas, em outros contextos, em que as necessidades sejam distintas, o TCP poderá ser uma escolha acertada.
Uma vez que a própria arquitectura protocolar TCP/IP possui uma grande independência relativamente a infra-estruturas de rede como o tipo de cablagem, os equipamentos ou a topologia, o protocolo OSC liberta- se automaticamente destas preocupações de “baixo nível”, podendo ser aplicada de uma forma simples a praticamente qualquer tipo de rede.
2.3.3 Implementação do protocolo OSC
Alguns exemplos de aplicações ou ambientes de programação com suporte para o protocolo OSC são o Supercollider1, o Max/MSP2, o Pure Data (Pd)3, o Open Sound World (OSW)4, o CSound5 e o Reaktor6. Existem ainda extensões para aplicações como o Adobe Flash,7 Director, ou até para linguagens como Perl,
1 http://www.audiosynth.com/ 2 http://www.cycling74.com/products/maxmsp 3 http://puredata.info/ 4 http://osw.sourceforge.net/ 5 http://www.csounds.com/ 6 http://www.native-instruments.com/#/en/products/producer/reaktor-5/ 7
Python, PHP ou Matlab1 que proporcionam também a possibilidade de utilização deste protocolo nesses contextos [52].
Em termos comerciais, é ainda clara a proliferação do protocolo MIDI. Enquanto o protocolo OSC não for suportado e adoptado pelas grandes marcas de produtos em hardware (Roland, Yamaha, Korg, etc.) bem como pelas marcas que desenvolvem o software, receamos que este protocolo, apesar de tecnologicamente superior, não venha a destronar o ainda útil MIDI. E esta implementação, em nosso entender, pode eventualmente depender da criação de uma espécie de modo de emulação do MIDI dentro do OSC, que possa de alguma forma garantir a retro-compatibilidade com todos os equipamentos MIDI produzidos nestes últimos 20 anos. O protocolo MIDI está de tal forma enraizado na indústria que, provavelmente, só uma mudança progressiva, de continuidade e não de ruptura, a nível tecnológico, poderá acabar por o “destronar” em termos comerciais.
Vimos já anteriormente que o MIDI define o “significado musical” dos vários tipos de mensagens como o
Note On/Off, Control Change ou o Pitch Bend. Existem apenas duas excepções a esta regra: as mensagens de System Exclusive e algumas mensagens de Control Change que não estão definidas.2 A normalização de parâmetros por parte do protocolo MIDI facilitou a sua adopção por parte da indústria, permitindo uma mais simples comunicação entre equipamentos e software.
Sendo o OSC um protocolo muito mais aberto, não define à partida este tipo de dados, deixa a cargo de cada equipamento ou software a definição do tipo de mensagens que pode enviar ou interpretar. Este “problema” tem dificultado a adopção do OSC como substituto do MIDI, apesar de tecnologicamente, este protocolo ter todas as potencialidades para o fazer. A definição de um conjunto de parâmetros por parte do protocolo OSC que simule as funcionalidades da especificação MIDI poderia facilitar imenso essa adopção por parte da indústria, sem desvirtuar a possibilidade de uma utilização mais “aberta” e experimental.
1
http://andy.schmeder.net/software 2
Estes dois tipos de mensagens não possuem qualquer atribuição de significado por parte da especificação MIDI, podendo ser implementados de forma livre por parte dos fabricantes de hardware/software.