Home / Segnali di Controllo / OSC – Open Sound Control (parte 1)
MATRIX - OSC - Open Sound Control (parte 1)

OSC – Open Sound Control (parte 1)

La trasmissione e la gestione di dati, parametri e più in generale di informazioni all’interno di un sistema o tra più sistemi interattivi, rappresentano le prime problematiche che i musicisti e i compositori di musica elettroacustica si sono ritrovati ad affrontare. Il problema era così rilevante da influire sulla natura e la genesi dell’opera stessa; come sempre accade, le importanti questioni tecniche intervengono radicalmente nei processi compositivi.

manta

In questa serie di articoli, si cercherà di tracciare un percorso che descriva i passaggi più importanti della storia dei mezzi e dei protocolli di trasmissione di dati. S’inizierà dal Controllo in Voltaggio per poi passare alla nascita del protocollo MIDI, si accennerà ad altri protocolli che hanno cercato di contrastare la sua egemonia (avallata dall’industria degli strumenti musicali) come lo SKINI, lo ZIPI, il FUDI (specifico per Pure Data ). Infine, approfondiremo e ci soffermeremo lungamente sull’ultimo nato tra i protocolli di trasmissione dati: l’OSCOpen Sound Control. Sarà posta molta attenzione all’OSC poiché non si tratta di un semplice antagonista del MIDI, ma di una vera rivoluzione nell’ambito dell’interazione tra sistemi paragonabile in importanza a quella avvenuta quando si è passati dal Controllo in Voltaggio (dominio analogico) al MIDI (dominio digitale).



Quarta parte

OSC – Open Sound Control

OpenSound Control (“OSC”) è stato creato dal CNMAT (Berkeley University) nel 1997 ed è un protocollo “open
source” per la comunicazione tra computer, sintetizzatori audio e altri dispositivi
multimediali.

OSC è progettato per supportare un’architettura client/server. I dati OSC sono trasmessi in
unità denominate pacchetti.
OSC è un protocollo di alto livello: non si occupa del meccanismo di trasmissione dei dati.
La rete che trasporta un pacchetto OSC è responsabile della consegna sia del contenuto
che del dato riguardante la sua grandezza.
Un pacchetto OSC può essere rappresentato in un datagramma come un protocollo di
rete UDP. In un protocollo basato sul flusso di dati come il TCP, il flusso dovrebbe
iniziare con un int32 che dia la dimensione del primo pacchetto seguito dal suo contenuto,
a seguire la dimensione del secondo pacchetto seguito dal suo contenuto e così via.
Tutto ciò che manda (una macchina, un’applicazione ecc.) messaggi OSC (sotto forma di
pacchetti) è un client.
Tutto ciò che riceve (una macchina, un’applicazione ecc.) messaggi OSC (sotto forma di
pacchetti) è un server.

Quando è stato introdotto OSC, è stato pubblicato OSC-client.c, una libreria C per la
costruzione di pacchetti OSC. Un client OSC che crei in modo corretto pacchetti e che li
distribuisca attraverso una rete è l’unica cosa da implementare.
CNMAT ha anche sviluppato due utilities che utilizzano un’interfaccia a riga di comando
(CLI) text-based Unix il cui compito è quello di formattare e spedire via UDP messaggi
OSC all’indirizzo e numero di porta interessati (sendOSC) oppure ricevere da una
determinata porta un messaggio e riportarlo in formato ASCII (dumpOSC). Per facilitare la
diffusione di OSC, CNMAT ha nel 1998 rilasciato anche un kit di OSC in forma di codice
sorgente che implementa la maggior parte delle caratteristiche necessarie per un server
OSC. Tutte le implementazioni di OSC attuali inviano e ricevono pacchetti OSC solo come
pacchetti UDP.

Un pacchetto OSC è composto di un blocco contiguo di dati binari e di un dato riguardante
la sua grandezza espressa in bytes che è sempre un multiplo di 4.
Il contenuto di un pacchetto OSC deve essere un messaggio OSC o un bundle OSC. Il
primo byte del contenuto del pacchetto distingue in modo inequivocabile tra queste due
possibilità.

I messaggi OSC consistono in tre parti:

address pattern è una stringa che specifica l’entità o le entità all’interno del server
OSC a cui è diretto il messaggio e che tipo di messaggio si tratta.
• un type tag string specifica il tipo di dati di ogni argomento
arguments sono i dati contenuti nel messaggio

Per esempio, un messaggio OSC potrebbe essere:
address pattern /additiva/sine5/freq
type tag string float
arguments 563,32

1 – Arguments

Una sequenza di argomenti OSC è rappresentata da una sequenza contigua di
rappresentazioni binarie di ciascun argomento. Ogni messaggio può contenere 0 o più
argomenti. Gli argomenti tipicamente sono numeri o stringhe.
Esempi di stringhe OSC:

Stringa OSC lunga quattro byte:

fig.1

Stringa OSC lunga otto bytes:

fig 2

2 – Tipi di dati e Type Tag String

Ufficialmente i tipi di dati OSC sono:
int32 – intero a 32 bit
OSC-timetag – numero a 64 bit a virgola fissa (fixed-point)
float32 – numero a 32 bit a virgola mobile (floating-point)
stringhe OSC – una sequenza di caratteri ASCII (non nulli) seguiti da uno null. Per
ottenere un numero di bit pari a un multiplo di 32, le stringhe OSC possono avere a
seguire da 0 a 3 ulteriori caratteri nulli.
blob OSC – un intero a 32 bit seguito da una serie di bytes arbitrari. Per ottenere un
numero di bit pari a un multiplo di 32 si può avere a seguire da 0 a 3 ulteriori bytes
nulli.
La grandezza di ogni tipo di dato in OSC è un multiplo di 32 bit. Questo garantisce che se
l’inizio di un blocco di dati OSC è allineato a 32 bit, ogni numero nei dati OSC sarà
correttamente allineato a 32 bit.

OSC consente anche l’uso di:
64-bit numbers
RGBA color
• “True” e “False

Un OSC type tag string è una stringa OSC che inizia con il carattere “,” (virgola) seguito da
una sequenza di caratteri corrispondenti esattamente alla sequenza di OSC Arguments.
Ogni carattere dopo la virgola è chiamato OSC type tag string e rappresenta il “tipo” del
corrispondente OSC arguments. Il requisito per gli OSC type tag string di iniziare con una
virgola rende più facile per il destinatario del messaggio OSC determinare se tale
messaggio è mancante di un OSC type tag string.
La tabella seguente elenca la corrispondenza tra ogni OSC type tag string e il tipo del suo
OSC arguments corrispondente:

fig 3

Alcune applicazioni OSC comunicano tra le loro istanze con ulteriori tipi di argomenti non
standard. Le applicazioni OSC non sono tenute a riconoscere questi tipi; un’applicazione
OSC dovrebbe scartare qualsiasi messaggio il cui OSC type tag string contenga un OSC
type tag non riconosciuto. Un’applicazione che faccia uso di un qualche tipo aggiuntivo
deve codificarlo con gli OSC type tag della seguente tabella:

fig 4

3 – Address Space e Address Pattern

Ogni Server OSC ha un set di OSC Methods. Gli OSC Methods sono le potenziali
destinazioni di messaggi OSC ricevuti dal Server OSC e corrispondono a ciascuno dei
punti di controllo che l’applicazione mette a disposizione. “Invocare” un OSC Methods
equivale a chiamare una “procedura”, ossia fornire argomenti al metodo e causare degli
effetti.
Gli OSC Methods di un Server OSC sono organizzati in una struttura ad albero chiamata
OSC Address Space”. Le foglie di questo albero sono gli OSC Methods e i nodi che si
diramano sono detti OSC Containers.
Ogni OSC Methods e ogni OSC Containers, tranne la radice dell’albero, hanno un nome
simbolico, una stringa di caratteri ASCII stampabili diversi dai seguenti:

fig.5

Ogni nodo dell’address space ha un nome simbolico ed è una potenziale destinazione per
i messaggi OSC.
Ogni server OSC definisce un proprio address space in base:
• alle caratteristiche offerte dall’ambiente;
• alla logica di chi ha programmato questo ambiente.

Questa logica è diametralmente opposta a quella dei protocolli quali ZIPI e MIDI che
tentano di definire in anticipo sia le architetture delle apparecchiature riceventi, sia i tipi di
messaggi stessi.
L’OSC Address di un OSC Method è un nome simbolico che dà il percorso completo
all’OSC Method nell’OSC Address Space, partendo dalla radice dell’albero. Un OSC
Address di un OSC Method inizia con il carattere “/” (forward slash), seguito dai nomi di
tutti gli OSC Containers, in ordine, lungo il percorso dalla radice dell’albero all’OSC
Method separati da caratteri slash, infine troviamo il nome dell’OSC Method. La sintassi
degli indirizzi OSC è stata scelta in modo che corrisponda alla sintassi degli URL.
es.
/additiva/sine5/freq

Un OSC Address Space di un server OSC può essere dinamico, cioè il suo contenuto e la
forma può cambiare nel tempo, quindi il sistema di query di OSC (descritto di seguito)
prevede un meccanismo per scoprire l’attuale indirizzo.

Ogni messaggio OSC contiene un address pattern (un modello di indirizzo) non un OSC
Address.

Quando un Server OSC riceve un OSC Message, questi deve invocare l’appropriato OSC
Method nel suo OSC Address Space basato sull’OSC Address Pattern dell’OSC Message.
Questo processo è chiamato dispatching (spedizione) dell’OSC Message all’OSC
Methods che farà il match (la corrispondenza) con il suo OSC Address Pattern. Tutti gli
OSC Methods che trovano corrispondenza sono invocati con lo stesso argomento, cioè
con gli OSC Arguments degli OSC Message.
Le parti di un OSC Address o di un OSC Address Pattern sono le “substringhe” tra coppie
adiacenti di slash o la “substringa” dopo l’ultimo slash.
Un OSC Message ricevuto deve essere spedito a ogni OSC Method nel corrente OSC
Address Space il quale OSC Address corrisponderà all’OSC Address Pattern dell’OSC
Message. Un OSC Address Pattern corrisponderà a un OSC Address se:

1. l’OSC Address e l’OSC Address Pattern contengono lo stesso numero di parti;
2. ogni parte dell’OSC Address Pattern corrisponde con la parte corrispondente
dell’indirizzo OSC.

Una parte di un OSC Address Pattern corrisponde a una parte di un OSC Address se ogni
carattere consecutivo nell’OSC Address Pattern corrisponde alla successiva consecutiva
substringa dell’OSC Address e ogni carattere nell’OSC Address è corrispondente a
qualcosa nel OSC Address Pattern. Queste sono le regole di corrispondenza per i caratteri
negli OSC Address Pattern:

1. ‘?’ negli OSC Address Pattern fa il matching di ogni singolo carattere;
2. ‘*’ negli OSC Address Pattern fa il matching di ogni sequenza di zeri o più caratteri;
3. Una stringa di caratteri tra parentesi quadre (es. “[string]”) negli OSC Address
Pattern
fa il matching di ogni carattere nella stringa. All’interno delle parentesi
quadre, il segno meno (-) e il punto esclamativo (!) hanno un significato particolare:
• Due caratteri separati da un segno meno indicano un range di caratteri
che corrisponde a quelli compresi tra i due in sequenza. (es. a-d equivale
a “a,b,c,d”)
• Un punto esclamativo all’inizio di una stringa racchiusa tra parentesi nega
il senso della lista, in altre parole significa che la lista fa il matching di
ogni carattere che non è nella lista.
4. Una lista separata da virgole in una stringa all’interno di parentesi graffe
(es.”{foo,bar}”) negli OSC Address Pattern fa il matching di ogni stringa nella lista.
5. Ogni altro carattere in un OSC Address Pattern fa il matching solo dello stesso
carattere.

Esempi di OSC Address:
/a/b/cde
/a/b/c/d/e
Esempio di OSC Pattern:
/?/b/*c

4 – Bundle

Un bundle è una sequenza di messaggi e/o bundle. Tutti i messaggi nello stesso bundle
devono essere elaborati dal server OSC atomicamente, in altre parole è come se tutti i
messaggi nel bundle fossero trattati in un solo istante, come una sola entità. Un pacchetto
OSC può essere un bundle o un unico messaggio. Ogni bundle ha un “time tag” che si
occupa della sincronizzazione dei singoli messaggi contenuti in esso e il suo formato è
quello utilizzato dal Network Time Protocol Internet (NTP).

Un OSC Bundles è costituito da:
• la stringa “#bundle”
• un OSC Time Tag
• zero o più OSC Bundle Elements

L’OSC Time Tag è un numero a 64 bit a virgola fissa descritto semanticamente di seguito.
Un OSC Bundle Element consiste in una parte che ne indica la grandezza (un int32 che
indica quanti bytes pesa il contenuto del Bundle Element, deve essere sempre un multiplo
di 4) e in un’altra che ne è il contenuto stesso. I contenuti possono essere sia OSC
messages sia altri OSC Bundle. I Bundle, in effetti, possono contenere altri Bundle.
La tabella che segue mostra le parti di un OSC Bundle formato da 2 o più elementi e la
grandezza in bytes (8 bit) di ogni parte.

fig.6

5 – OSC Time Tags

Un server OSC deve avere accesso a una corretta rappresentazione del tempo attuale in
assoluto. OSC non fornisce alcun meccanismo per la sincronizzazione del clock. Quando
un pacchetto OSC contenente un singolo messaggio viene ricevuto, il server OSC
dovrebbe invocare il corrispondente OSC Method immediatamente, vale a dire, il più
presto possibile dopo la ricezione del pacchetto. Diversamente, quando viene ricevuto un
pacchetto OSC contenete un OSC Bundle è il Time Tag OSC di quest’ultimo che
determina quando gli OSC Method corrispondenti agli OSC Messages (contenuti nell’OSC
Bundle) debbano essere invocati.
Se il tempo rappresentato dal Time Tag OSC è precedente o uguale al tempo attuale, il
server di OSC dovrebbe invocare gli OSC Method immediatamente (salvo che l’utente non
abbia configurato il server OSC affinché elimini i messaggi che arrivino troppo tardi). Nel
caso contrario che il Time Tag OSC rappresenti un momento nel futuro, il server OSC
deve memorizzare il pacchetto OSC fino al momento specificato e solo allora invocare gli
OSC Methods appropriati.
I Time Tag OSC sono rappresentati da un numero a 64 bit a virgola fissa (fixed-point). I
primi 32 bits specificano il numero di secondi dalla mezzanotte del primo gennaio del
1900, mentre i successivi 32 bits specificano la parte frazionaria di secondo con una
precisione di circa 200 picosecondi. Questa è la rappresentazione usata dal protocollo
NTP in internet. Se il valore del Time Tag è costituito da 63 bits a zero e seguito da uno
nella posizione del meno significativo, allora questo è il caso speciale che significa
“immediatamente”.
Gli OSC Messages nello stesso OSC Bundle sono “atomici”; i loro OSC Methods
corrispondenti devono essere invocati in immediata successione, nessun altro tipo di
elaborazione deve aver luogo tra le varie invocazioni degli OSC Methods.
Quando un OSC Address Pattern è inviato a multipli OSC Methods, l’ordine nel quale i
corrispondenti OSC Methods sono invocati non è specificato.
Quando un pacchetto OSC contiene diversi OSC Messages, il set di OSC Methods
corrispondenti agli OSC Messages deve essere invocato rispettando lo stesso ordine di
successione dei messaggi OSC all’interno del pacchetto.
Quando i Bundles contengono altri Bundles, il Time Tag OSC del Bundle più interno
(racchiuso) deve essere più grande o quanto meno uguale a quello del Bundle più esterno
(che racchiude). Il requisito di “atomicità” per gli OSC Messages in uno stesso Bundle non
è applicata a quelli del Bundle di livello inferiore (racchiuso)

6 – Queries

Le queries sono messaggi OSC che chiedono al server di rimandare delle informazioni al
client. Tipologie di queries eseguibili sono:
“Qual è la lista aggiornata dei nodi che si trovano al di sotto di questo nodo?”
“Quali tipi di argomenti ci si aspetta per i messaggi inviati a questo dato nodo?”
“Qual è l’attuale valore del parametro che si sta settando mandando questo messaggio?”
“Prego inviarmi la documentazione per l’oggetto o la funzionalità specificato da questo
indirizzo”.

7 – Ambienti di programmazione musicali che implementano OSC

Max/MSP
Il primo ad utilizzare l’OSC è stato Max/MSP con delle externals scritte da Matt Wright.
Attualmente le versioni più aggiornate di queste externals fanno parte di un pacchetto
software scaricabile direttamente dal sito del CNMAT denominato Max/MSP/Jitter, che
comprende oltre quelle dedicate al protocollo OSC anche una interessante serie di patch
destinate alla sintesi e all’analisi di segnali audio e le patch del pacchetto MMJ-Depot.
L’oggetto OpenSoundControl trasforma i dati in formato Max in dati binari formattati OSC e
viceversa.
Gli udpsend e udpreceive mandano e ricevono pacchetti UDP e possono essere usati in
combinazione con l’oggetto OpenSoundControl visto sopra.
Questi oggetti sono implementati separatamente per consentire di trasmettere pacchetti
OSC che non siano in formato UDP e di trasmettere pacchetti UDP che non siano
messaggi OSC.
Infine abbiamo OSC-route, capace di analizzare gli address patterns e gestisce le
“corrispondenze”.
L’implementazione in Max supporta perfettamente la trasmissione di messaggi e bundles
ma attualmente non vi è integrazione tra i Time Tag OSC e lo scheduler di Max e inoltre
non vi è supporto per le query.
L’atomicità temporale dei bundles è gestita dal fatto che l’oggetto OpenSoundControl invia
un bang dopo l’invio di tutti i messaggi in un bundles, ma è responsabilità dello
sviluppatore della patch garantire la corretta gestione temporale dei messaggi.
Altri oggetti OSC sono:
OSC- schedule – gestisce lo scheduling dei bundle;
OSC-timetag – genera, trasforma e manipola Time Tag.

SuperCollider
James McCartney ha implementato il supporto a OSC a SuperCollider nel 1998.
L’oggetto OSCNode rappresenta un nodo dell’address space e contiene un nome
simbolico, un elenco dei sotto-nodi, e una funzione da chiamare quando il nodo riceve un
messaggio.
Gli oggetti OSCOutPort e OSCInPort rappresentano le porte UDP che possono inviare o
ricevere (rispettivamente) i pacchetti OSC. Ogni OSCInPort ha un OSCNode che è la root
dell’address space associati a quella porta.
OSCresponder e OSCresponderNode registrano una funzione da chiamare dopo aver
ricevuto un comando specifico da un indirizzo specifico OSC. OSCresponderNode
permette di attivare responder multipli con lo stesso comando.
Ci sono un grande numero di messaggi OSC che possono essere mandati a
SuperCollider, del tipo: “run the main patch”, “stop synthesis”, “play this sound file from the
local disk
”, “compile and execute the code in the string argument to this message”.
Ci sono anche la rappresentazione di tutti i più importanti messaggi midi (note on/off,
continuous controllers, pitch bend, program change, channel and key pressure, and all-
notes-off
). Quando SuperCollider riceve uno di questi messaggi OSC, è esattamente
come se avesse ricevuto il corrispondente messaggio MIDI attraverso un MIDI input.
L’attuale versione è SC3 è stata completamente ridisegnata e ha una nuova architettura
chiamata SuperCollider Server. In questa versione il motore di sintesi è un’applicazione
separata dal linguaggio SC e dall’ambiente di sviluppo. I due comunicano esclusivamente
con messaggi OSC via UDP o TCP. Questo permette al motore di sintesi di SC di essere
controllato da altre applicazioni oltre che dal linguaggio SC. Attualmente SC è quindi il
software con la maggiore integrazione con OSC essendone diventato uno dei meccanismi
di base del suo funzionamento.

Open Sound World
OSW è un linguaggio scalabile, estensibile e object-oriented che permette di ottenere
sintesi sonora come risposta a controlli in real-time. OSW ha lo stesso modello di dataflow
grafici e nidificati, strutture subpatch, ecc. del linguaggio Max; una differenza importante è
che ogni oggetto OSW ha un nome simbolico. Così, gli oggetti in una patch OSW
automaticamente formano un address space gerarchico in stile OSC e questo facilità
l’interfacciamento con messaggi OSC; il kernel OSW gestisce questo automaticamente.
OSW fornisce anche un oggetto chiamato OSCListen che può essere utilizzato per
elaborare manualmente i messaggi OSC in arrivo. Questo permette ai programmatori
OSW di costruire un address space OSC che non rifletta necessariamente la struttura ad
albero di un programma OSW che funzioni da server OSC.
OSW ha il miglior supporto alle query OSC grazie la lavoro di Andy Schmeder presso il
CNMAT. Attualmente non esiste un collegamento tra i Time Tag OSC e la gestione del
current time di OSW. Un programmatore attento può utilizzare i meccanismi degli
synchronous outlets” per garantire che tutti gli elementi all’interno di un bundle siano
trattati atomicamente.

Pure Data
Il supporto ad OSC in PD è dato da oggetti implementati da terze parti. L’uso degli oggetti
sendOSC e dumpOSC, il cui compito era di mandare e ricevere pacchetti OSC, è ormai
desueto e non più implementato. Allo stato attuale, è necessario che all’apertura dell’applicazione venga
caricata la libreria “mrpeach”, ciò consentirà di poter utilizzare gli oggetti:
packOSC (formatta messaggi in formato OSC da mandare via UDP);
unpackOSC (accetta liste di float che sono interpretate come pacchetti OSC);
routeOSC (capace di analizzare gli address patterns e gestire le “corrispondenze”).
Questi oggetti sono da usare in combinazione con udpsend e udpreceive, i quali sono
abilitati a gestire porte di rete (socket) per l’invio e la ricezione di pacchetti via UDP. I Time
Tag
OSC sono ignorati e non vi è nessun meccanismo che gestisce l’atomicità temporale
dei bundles. RouteOSC è derivato dall’omonimo oggetto di Max/MSP, inoltre PD non
supporta le queries.

Virtual Sound Server
VSS è uno strumento per la sintesi interattiva in real-time ed è stato progettato per essere
utilizzato in combinazione a software di rendering grafico. Include meccanismi per la
sincronia dell’audio prodotto da esso in real-time con altre applicazioni video.
VSS può essere controllato con una forma limitata di OSC utilizzando un address space
generico. Non vi è supporto per:
tag di tipo stringa
bundles
Time Tag OSC
queries
• ”corrispondenze

Csound
Il supporto ad OSC in Csound è stato implementato in un primo momento solo come kit
aggiuntivo per una release non ufficiale per Linux. Nell’attuale versione ufficiale di
Csound (si fa riferimento alla versione 5.17.6) vi è supporto per tutti i sistemi operativi. Per gli esempi pratici presentati in seguito
si è fatto uso del frontends QuteCsound nella versione 0.6.1 per Mac.
Questa implementazione permette di definire orchestre che possono essere controllate da
OSC. Si possono definire elementi in un generico address space OSC, ma la sua struttura
ad albero complessiva è vincolata dal fatto che tutti gli strumenti Csound sono allo stesso
livello. Il meccanismo per gestione dei messaggi in input e in output è affidata ad una
procedura a k-rate.

8 – Linguaggi di programmazione generici che implementano OSC

Java
Chandrasekhar Ramakrishnan ha implementato delle classi in Java che possono creare
pacchetti OSC attraverso un’interfaccia procedurale e mandarli in un pacchetto UDP. Vi è
supporto per i tags ma non per i Time Tag OSC. Future implementazioni prevedono la
possibilità di ricevere OSC.
Inoltre, ha anche costruito in Objective-C un wrapper OSC-Client.c per consentire ad
applicazioni Cocoa di mandare messaggi OSC.

Perl
C’è un’implementazione di OSC in Perl. L’output è gestito dal programma sendOSC
compilato con SWIG (http://www.swig.org), l’input con dumpOSC. Quest’ultimo offre una
funzione chiamata ParseOSC che legge in un pacchetto OSC (ricevuto attraverso
l’implementazione interna UDP di Perl) e restituisce gli address patterns e gli argomenti di
un messaggio OSC.

Python
Ci sono due implementazioni OSC per Python, entrambe sono files in codice sorgente
Python con il nome OSC.py. PyOSC di Daniel Holth e Clinton McChesney (del progetto
ProctoLogic) traduce bidirezionalmente il formato binario di OSC in formato dati Python. I
bundles sono letti correttamente ma non possono essere costruiti. Inoltre include un
CallbackManager che permette di associare chiamate Python a OSC addresses e poi
spedire messaggi OSC. Non sono supportate le “corrispondenze”.
OSC.py di Stefan Kersten è un modulo Python per client OSC. Può costruire pacchetti
OSC e mandarli in pacchetti UDP. È capace di creare Time Tag OSC basati su procedure
Python built-in time.

Smalltalk
Smalltalk ha due implementazioni OSC:
VWOSC capace solo di mandare messaggi OSC
Siren un framework con delle sperimentali implementazioni OSC

9 – Software per il Web che implementano OSC

Flash
Il software Flash di Macromedia, che consente di creare animazioni vettoriali per il web,
contiene ActionScript, un linguaggio capace di manipolare documenti XML (XML è un
meta-linguaggio per definire la struttura di documenti e dati, un documento XML è un file
di testo che contiene una serie di tag, attributi e testo secondo regole sintattiche ben
definite). ActionScript ha un meccanismo che manda e riceve documenti XLM attraverso
TCP/IP socket. Ben Chun ha definito un tipo di documento XML per rappresentare i
pacchetti OSC in XML e ha creato un gateway (un dispositivo capace di veicolare
pacchetti in rete) bidirezionale tra Flash e OSC con un programma chiamato Flosc che
traduce pacchetti OSC su UDP in documenti XLM su TCP e viceversa.

Macromedia Director
Macromedia Director e un software che consente la creazione di applicazioni multimediali
stand-alone che possono essere distribuite anche tramite Web. Come strumento di
authoring multimediale, Macromedia Director è in grado di incorporare immagini di qualità
fotografica, suoni, animazioni, modelli 3D, testi, ipertesti, immagini bitmap e contenuti
Macromedia Flash. Garry Kling presso l’Università di Santa Barbara in California ha scritto
una estensione (“xtra”) per Macromedia Director chiamata OSCar che manda pacchetti
dal linguaggio script ad oggetti Lingo (incorporato in Director). Si prevede una futura
implementazione per la funzione di ricezione dei pacchetti.

10 – Esempi di sistemi hardware che gestiscono OSC

Kroonde Gamma

kroonde_gamma

Kroonde Gamma è un’interfaccia progettata per applicazioni in tempo reale. Questo
sistema riceve dati da sensori wireless come pressione, flessione, accelerazione, campo
magnetico, e sensori di luce ecc. Il Kroondle è formato da un piccolo trasmettitore al quale
si possono collegare fino a sedici sensori analogici, questo trasmette i dati a un’interfaccia
ricevente via wireless. I sensori sono collegati al trasmettitore tramite due connettori a otto
canali. Il sistema Kroonde comunica usando tre differenti protocolli:
OSC
FUDI
MIDI
I messaggi OSC inviati dal Kroonde sono liste di valori del sensore. Quando si utilizza un
set di otto sensori, il Kroonde manda una lista di otto elementi come argomento di un
messaggio “/kroonde“. In questa lista, ogni elemento corrisponde al valore del suo
sensore. Quando si utilizzano due gruppi di otto sensori, la lista trasmessa ha sedici
elementi corrispondenti ai valori dei sedici sensori collegati.

MATRIX
MATRIX

Dan Overholt ha costruito un’interfaccia chiamata MATRIX (“Multipurpose Array of Tactile
Rods for Interactive eXpression
“) che consiste in una matrice di 144 barre (12×12)
montate su molle ciascuno in grado di muoversi in verticale. MATRIX è iniziato come un
progetto di collaborazione tra l’Hyperinstrument and Interactive Cinema groups e il MIT
Media Lab
. La posizione delle barre è mappata per controllare direttamente la forma
d’onda del suono, le informazioni ottenute sono trasmesse in modo seriale a un computer
che li converte in messaggi OSC che vengono utilizzati per la sintesi sonora affidata a
SuperCollider e MAX.

JazzMutant Lemur
lemur1

Controller dotato di display multi-touch, con interfaccia modulare e programmabile,
trasmette dati via MIDI e OSC. Molto costoso, attualmente è da considerarsi superato
poiché è possibile ottenere le stesse funzionalità da combinazioni di sistemi hardware e
software molto più economici: ad esempio un Tablet con un applicazione del tipo
TouchOSC.

MONOME
monome

È un controller semiartigianale dal design molto curato che si comporta da client OSC. Fa
uso di una matrice di pulsanti retroilluminati configurabili ed è costruito in varie dimensioni
anche su richiesta. È da menzionare questo hardware commerciale poiché il suo essere
“costumizzabile” su richiesta ha attirato una serie di appassionati i quali si sono dedicati
all’autocostruzione di controller sulla falsariga del Monome, in particolare l’Arduinome
che si basa sull’utilizzo di Arduino.

11 – Applicazioni musicali basate su rete che utilizzano OSC

Dal documento ufficiale del CNMAT presentato al NIME del 2003
vengono riportati
alcuni esempi di applicazioni di OSC in campo artistico.

– All’ICMC 2000 a Berlino (http://www.audiosynth.com/icmc2k) una rete di dodici computer
Mac esegue della sintesi sonora con SuperCollider scambiandosi i parametri con OSC.
Questa istallazione si ispira alla composizione “Rainforest” di David Tudor.

– Il Meta-Orchestra project è una vasta rete locale che usa OSC

– “Collaborative Intermedia WorkTelemusic #1 di Randall Packer, Steve Bradley e John
Young. I visitatori di un sito web interagiscono con controlli Flash che hanno effetto sulla
sintesi del suono in un luogo fisico. Il suono ottenuto viene trasmesso di nuovo agli utenti
web con RealAudio. Questo sistema è stato implementato prima della creazione di Flosc e
di XMLSockets per Flash. Il percorso dei dati quindi è Flash > JavaScript > Java > OSC.

– Presso l’UIUC (University of Illinois at Urbana–Champaign) sono stati sviluppati vari
progetti basati su sistemi che effettuano del tracking spaziale 3D in tempo reale di un
oggetto fisico, i dati ottenuti sono elaborati e inviati con OSC a calcolatori che con
Max/MSP elaborano la sintesi del suono:
eviolin project, una macchina Linux traccia la posizione spaziale di un violino
elettrico e mappa i parametri spaziali per controllare un modello di risonanza in
tempo reale. Il suono del violino è poi processato attraverso questo modello.
Interactive Virtual Ensemble project, un direttore indossa dei sensori magnetici
wireless che mandano dei dati sulla posizione e l’orientamento a un ricevitore
connesso a un calcolatore SGI Onyx che processa i dati dei sensori. In questo
sistema, Max/MSP ottiene via OSC dalla SGI Onyx i valori correnti del sensore.
VirtualScore è un ambiente audiovisivo immersivo per la creazione di
rappresentazioni grafiche 3D del materiale musicale. Anche in questo caso si fa uso
di OSC per la trasmissione dei dati.
– Il Circular Optical Object Locator del CCRMA dell’Università di Stanford si basa su un
piatto rotante sul quale gli utenti sistemano degli oggetti opachi. Una videocamera digitale
riprende il piatto e un software processa le immagini analizzando la posizione degli oggetti
e la velocità di rotazione del piatto. I dati in uscita da questa elaborazione vengono inviati
via OSC ad un altro computer sul quale tramite Max/MSP avviene la sintesi sonora.

Listening Post è un’istallazione multimediale di Mark Hansen e Ben Rubin che estrae
frammenti di testo in tempo reale da migliaia di chat su Internet, bacheche e altri forum
pubblici contenenti le parole “i am”. I testi sono letti (o cantati) da un sintetizzatore vocale,
e contemporaneamente visualizzate su una griglia sospesa di oltre duecento piccoli
schermi elettronici. La sonificazione avviene attraverso un sistema di 10 altoparlanti. Una
rete locale di 4 computer gestisce la visualizzazione del testo, il “text-to-speech”, la sintesi
del suono, e il coordinamento di tutti questi elementi. Tutti i componenti del sistema
comunicano con OSC. Listening Post è attualmente in mostra al Whitney Museum of
American Art
.

– Il gruppo di ricerca CREATE dell’Università di Santa Barbara in California ha lavorato su
“sistemi per la distribuzione di multimedia ad alte prestazioni” e “sistemi distribuiti di
rilevamento, computazione e presentazione”. Queste reti su larga scala sono tipicamente
costituite da sensori multipli per la realtà virtuale (head-trackers, hand-trackers ecc.) e da
dozzine di computers che elaborano gli input, realizzano simulazioni, eseguono rendering
audio e video, producono l’output di audio e video multicanale; tutto connesso con
COBRA (Common Object Request Broker Architecture – un’architettura per l’interazione
tra applicazioni) e OSC. Un altro progetto del CREATE combina COBRA e OSC per
consentire a un sistema per la realtà virtuale (formato da sensori per il movimento e
guanti) di mandare messaggi di controllo a software scritto in SuperCollider.

– Nel “Tgarden project”, realizzato da “Topological Media Lab”, accelerometri wireless
sono rilevati da una macchina Linux e mappati attraverso OSC per il controllo del suono e
la sintesi video in Max/MSP, SuperCollider, e NATO.

Esempi di utilizzo di OSC

I seguenti esempi sono stati creati dal sottoscritto e lasciati volutamente a un livello di base per
facilitarne la comprensione e l’eventuale modifica da pare di chi ne fosse interessato. Essi
sono stati tutti testati e perfettamente funzionanti in realtime.

Utilizzo di OSC con Csound

In questo esempio si varia frequenza e ampiezza di una sinusoide:

fig.7

Nei due esempi successivi (anch’essi lato server) si mandano e si ricevono messaggi OSC che:
• Attivano/disattivano toggle
• Muovono fader
• Ricevono/spediscono float

Utilizzo di OSC con Pure Data
fig.8

Utilizzo di OSC con Max/MSP
fig.9

Utilizzo di OSC con Supercollider

In questo esempio si varia frequenza e ampiezza di una sinusoide:

fig.10


Maurizio Zoccola

About Maurizio Zoccola