Home / Segnali di Controllo / ZIPI, SKINI e FUDI
hemis72 copy1 - ZIPI, SKINI e FUDI

ZIPI, SKINI e FUDI

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.

hemis72 copy2 - ZIPI, SKINI e FUDI
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).



Terza parte


Nel precedente articolo abbiamo analizzato la nascita e lo sviluppo del MIDI. Inoltre abbiamo anche posto l’accento su alcuni suoi limiti, come ad esempio la mancanza di flessibilità di fronte ad esigenze tecniche specifiche. E con gli sviluppi tecnologici, ulteriori limiti vengono a evidenziarsi. Negli anni ‘90 vi è una crescente diffusione dei calcolatori che consentono l’esecuzione di compiti sempre più impegnativi. Nascono nuove interfacce come la IEEE1394 comunemente detta Firewire, capace di trasmettere una notevole quantità di dati con velocità maggiore rispetto ai tradizionali collegamenti. Inizia a svilupparsi anche la tecnologia wireless basata sulle radiofrequenze. Lo sviluppo di queste tecnologie hardware va di pari passo con quello riguardante le connessioni di rete: nascono le reti LAN, WAN, si afferma internet ecc. In questo nuovo scenario il MIDI mostra grosse limitazioni e s’iniziano a progettare nuovi protocolli e sistemi di comunicazione capaci di sfruttare appieno queste nuove tecnologie: lo ZIPI, lo SKINI e il FUDI.

ZIPI – Zeta Instrument Processor Interface

Questo progetto di ricerca nasce come il MIDI in ambito commerciale grazie all’interessamento della Zeta Instruments, oggi nota casa produttrice di strumenti ad arco elettrificati.
zeta1 - ZIPI, SKINI e FUDI
Questa industria finanzia il progetto di ricerca che si tiene presso il CNMAT (Center for New Music e Audio Technologies) della Berkeley University. Nel 1994 ZIPI è annunciato alla comunità scientifica internazionale attraverso una serie di pubblicazioni sul Computer Music Journal. È un protocollo progettato per sfruttare le nuove tecnologie di rete e si basa sull’osservanza del modello OSI – Open Systems Interconnection (protocollo standard per la comunicazione, superato in seguito dal TCP/IP). Fisicamente il collegamento avviene attraverso una rete a stella con un Hub al centro che consente una maggiore flessibilità di collegamento superando il concetto di daisy-chain, ossia l’interconnessione seriale di dispositivi. Il protocollo non dipende da nessuna tipologia d’interfacciamento fisico specifico, anche se per gli studi di ricerca sono stati utilizzatati cavi Ethernet con connettori 10Base-T.

ZIPI utilizza un sistema di messaggi basato su un protocollo chiamato MDPL – Music Parameter Description Language. Nei propositi degli sviluppatori vi era l’intenzione di superare completamente la logica degli eventi e dei canali MIDI introducendo tre livelli gerarchici di indirizzi, ossia 63 famiglie, composte ognuna di 127 instruments, ciascuno con 127 note riuscendo così a raggiungere il numero di 1,016,127 indirizzi di note distinte:

zipi1 - ZIPI, SKINI e FUDI

Gli instruments in una famiglia possono essere riuniti da diversi dispositivi fisici. Questo tipo di organizzazione gerarchica è stato studiato per ottenere un minuzioso controllo dei singoli parametri di sintesi e per favorire alcuni tipi di controller fisici non standard come wind-controller e guitar-controller che fanno uso di maggiori e più accurati parametri di controllo. Un aspetto questo rilevante dello studio, essendo la Zeta Instruments un costruttore di strumenti non convenzionali interessata a implementare i risultati della ricerca sui suoi prodotti. Alcuni messaggi MDPL derivano direttamente dal MIDI, anche se hanno nomi diversi per evitare ambiguità, ma la maggior parte di essi sono nuovi e sono basati su controlli logici molto differenti ma innovativi: fanno riferimento ad avanzati parametri di programmazione come modulazioni, inviluppi e spazializzazione 3D di voci, oltre a messaggi specifici per guitar controller, wind controller e drum controller. La risoluzione in bit dei parametri dei messaggi è un multiplo di 8, estendendo la risoluzione del midi dai tipici 7 bit a 32 e più.

Tipi di Messaggi ZIPI:

I messaggi di controllo per la sintesi di base sono:

Articulation – ‘note on/off’ in MIDI
Pitch (note number and offset in 0.2 cents)
Frequency (in Hz)
Loudness – ‘velocity’ in MIDI
Amplitude – ‘volume’ in MIDI
Even/Odd Harmonic balance
Pitched/Unpitched balance
Roughness
Attack character
Inharmonicity
Pan Left/Right, Up/Down, Front/Back
Spatialization distance and azimuth/elevation angles
Program Change – immediately and future notes
Timbre space X/Y/Z
Multiple output levels
Time tag
Modulation rate/depth/wavetype

Messaggi per specifici per controllers (orientati alle performance):

Key Velocity/Number/Pressure
Pitch Bend Wheel
Mod Wheel 1/2/3
Switch pedal 1 (Sustain)/ 2 (Soft pedal) /3 /4
Continuous pedal 1 (Volume)/2 /3 /4
Pick/bow Velocity/Position/Pressure
Fret/fingerboard Position/Pressure
Wind flow or pressure (breath controller)
Embouchure (bite)
Wind controller keypads
Lip pressure/frequency
Drum head striking point X/Y position and distance/angle from center
X/Y/X position in space
Velocity in X/Y/Z dimension
Acceleration in X/Y/Z dimension

Con ZIPI assistiamo anche all’introduzione dei Tag-Time per la sincronizzazione dei messaggi, divenuti necessari trovandosi di fronte a un collegamento a stella e non più seriale che ne forzava lo scheduling. Assistiamo anche al tentativo di inserire la possibilità di eseguire query all’interno del sistema e di ottenere quindi informazioni riutilizzabili riguardo i parametri in uso. L’introduzione dei Tag-Time e delle queries interpreta la rinnovata esigenza di una tecnologia capace di far interagire i sistemi e non solo di connetterli tra di loro. Non ci dilunghiamo oltremodo nella descrizione tecnica del protocollo poiché il progetto ZIPI è stato presto abbandonato. Il sistema non ha mai trovato impiego né in ambito commerciale né in ambito scientifico e di ricerca. Le ragioni sono:

• Hardware complesso; ZIPI anche se non è legato a interfacce fisiche specifiche, richiedeva cablaggi più complessi e costosi rispetto al MIDI (rete a stella, hub).
• L’uso del protocollo di comunicazione OSI. ZIPI si basa su questo protocollo molto affidabile ma estremamente complesso, ragione per cui non ha avuto una grande diffusione ed è stato soppiantato dal TCP/IP.
MDPL ha uno schema di indirizzamento insolito che, confrontato con il MIDI, richiede un sostanziale incremento della complessità. La gestione di 1,016,127 singoli stati di sintesi era ben oltre le possibilità hardware del tempo. Gli stessi sviluppatori di ZIPI lasciarono intendere che vi fossero limiti pratici circa il numero simultaneo di note e programmi.
• Pur ponendosi come obiettivo principale il superamento concettuale del MIDI, nello sviluppare ZIPI si falli tale scopo.
• Mercato degli strumenti musicali ancora legato al MIDI. Questo era ritenuto ancora sufficiente e più economico ai fini dello svolgimento della maggior parte dei compiti richiesti. Inoltre la complessità del MDPL non ne favoriva la diffusione.
• Introduzione della “FireWire” (IEEE1394) come dispositivo fisico di comunicazione nelle apparecchiature, capace di garantire prestazioni superiori nella trasmissione dei dati. Ha requisiti di interfaccia più semplici, non necessita di hub, supporta il collegamento a caldo e comprende anche uno schema isolato capace di distribuire alimentazione elettrica.

Bisogna rimarcare però i meriti di questo tentativo che ha gettato le basi verso lo sviluppo di OSC. Una coppia di sviluppatori che avevano lavorato allo ZIPI, Matt Wright e David Wessel, formano un nuovo team di ricerca con Adrian Freed, Amar Chaudhary e Sami Khoury per sviluppare OSC, che pur non avendo nulla in comune con lo ZIPI, affronta molte delle problematiche sollevatesi con lo sviluppo di quest’ultimo:

• Esplorare le possibilità offerte dalle nuove tecnologie di comunicazione di rete.
• Superamento del collegamento seriale.
• Il tentativo di non essere legato a nessuna interfaccia fisica particolare.
• Incremento della velocità nella trasmissione dei dati.
• Introduzione dei Tag-time e della possibilità di eseguire Query.
• Ampliare il numero dei tipi di parametri e accrescere la minuziosità dei controlli in funzione dell’utilizzo di controllers non standard.
• Messaggi per controlli non convenzionali, inviluppi, loudness, spazializzazione, ecc.

Per i dettagli tecnici completi riguardo l’MDPL si faccia riferimento al documento ufficiale pubblicato nel 1994 sul Computer Musical Journal (Winter 94) “The ZIPI Music Parameter Description Language” di K. McMillen, D. Wessel e M. Wright.

SKINI

SKINI fa parte di un set di classi in C++ chiamato STK – Synthesis ToolKit creato da Perry Cook.
Perry Cook - ZIPI, SKINI e FUDI
Nello specifico STK è composto da algoritmi di sintesi e da processori di segnale scritti da P. Cook e da G. Scavone con attenzione alle funzionalità multipiattaforma, al real-time e alla facilità d’uso. STK è estremamente portabile (la sua principale piattaforma è il C e il C++) ed è open source. Perry Cook ha iniziato a sviluppare STK presso il CCRMAStanford University nei primi anni 1990.
Ecco alcune note redatte da Cook e tratte dall’originale distribuzione di STK:

STK è stato creato senza avere nessun sistema hardware come riferimento. Questi esempi intendono essere un tutorial. Sono la base per il continuo della mia ricerca e il punto di parenza per un sistema di sintesi software. Le motivazioni di base sono il creare le necessarie unità generative per fare sintesi, processing e controllo di quello che io voglio fare e insegnare….
Una domanda a questo punto potrebbe essere mossa: “ma con CMix, CMusic, CSound, CShells, CMonkeys etc., perché fare un nuovo set di funzioni per la sintesi musicale e il processing?”. Le risposte sono:
1. Necessitavo di riscrivere molte cose che avevo fatto in qualcosa di generico in modo da poter essere portato in futuro su differenti piattaforme.
2. Avevo la necessità di organizzare e documentare queste cose in modo da garantirne la comprensione con il passare del tempo.
3. Le classiche difficoltà di molte persone nel cercare di implementare i modelli fisici, ossia:

    • Problemi nel capire la documentazione e/o passare dalla teoria alla pratica;
    • Gli strumenti per i modelli fisici sono materia di “grande pena”, quindi dare un punto di partenza stabile e comprensibile è vantaggioso.

4. Io vorrei provare alcuni nuovi strumenti con la Sintesi Modale e implementare alcune classiche patches per l’FM.
5. Vorrei re-implementare dei modelli fisici di cui mi sono occupato in alcuni miei articoli. Ma lo vorrei fare in modo portabile e che i moduli siano collegabili velocemente. Mi piacerebbe ottenere che questi strumenti siano collegabili ad altri oggetti…”.

In questo set di classi C++ è compresa una chiamata SKINI il cui compito è di trasmettere e ricevere dati e parametri. SKINI è stata disegnata per essere compatibile con il MIDI ed espanderlo se possibile, quindi non di superarlo e di sostituirsi a esso. Le differenze con il midi sono:

• Favorire la leggibilità e portabilità. Vengono usati messaggi basati su testo, con nomi comprensibili dove è possibile. Ciò rende capace ogni linguaggio o sistema in grado di formattare testo di generare SKINI. Allo stesso modo, ogni sistema capace di leggere stringhe e trasformare campi in stringhe, float e int può utilizzare SKINI per il controllo. SKINI può essere scritto manualmente in file attraverso normali editors di testo.
Float numbers sono usati dove è possibile. Numeri di note, velocity, valori di controllo ecc. sono tutti rappresentati in codice ASCII. I byte in formato midi sono preservati in modo che, provenendo da una interfaccia essi possano essere inseriti direttamente in messaggi SKINI.

SKINI è stata scritta in modo da essere estendibile e adattabile a numerose applicazioni:
• Sintesi sonora integrata per videogiochi e realtà virtuale.
• Applicazioni dedicate alla notazione e al mixing.
• Applicazioni real-time.
• Applicazioni che non richiedono controllo per la sintesi del suono.
• Sintesi controllata da JAVA.

Un messaggio di base SKINI è una riga di testo. Sono richiesti solo tre campi: il tipo di messaggio (un nome ASCII), il tempo (un delta o un assoluto) e il numero di canale. Per canali non si intende quelli midi che comunque sono supportati. Il numero di canale è un long int e può fare riferimento a un numero di socket, un ID macchina, un serial number o un tag che identifichi un evento in una sintesi. Altri campi possono essere usati.
I campi in una riga SKINI sono limitati da spazi, virgole o tab. Il parser SKINI opera solo su una riga alla volta, così che una nuova riga significa un nuovo messaggio. Messaggi
multipli non sono ammessi su una singola riga. Nei tipi di messaggi sono inclusi i tipi standard dei messaggi midi come: NoteOn, NoteOff, ControlChange, etc. Sono implementati molti tipi di messaggi che non seguono gli standard del midi, dove è possibile, è auspicabile usarli come external midi in modo da poterli utilizzare in real-time.
Per concludere la descrizione di SKINI evidenziamo la sua natura open source; il MIDI e il tentativo fallito di ZIPI sono entrambi nati da esigenze commerciali. Con SKINI invece, grazie alle esigenze individuali di uno studioso, si ritorna nell’ambito libero della ricerca e della sperimentazione. La portabilità è un elemento a cui si è dedicato grande attenzione, così come per la leggibilità e l’accessibilità del codice: tipiche esigenze di un ricercatore che tiene conto dei possibili risvolti di futuri studi. Skini per sua natura è estendibile e si integra con svariate altre applicazioni. Rimane però anch’esso legato concettualmente al MIDI, in effetti non era stato concepito per sostituirlo. Usa parte della sua messaggistica e cerca di integrarsi con esso, anzi potremmo parlare di un tentativo di espanderlo; ricordiamo che nelle intenzioni di Cook vi era quella di far passare i messaggi specifici non standard come external midi, proprio per favorirne l’integrazione con i sistemi in uso. Non possiamo però ancora parlare di un protocollo standard e di un suo uso su vasta scala poiché stiamo parlando di una singola classe che fa parte di una libreria (STK) scritta in C++.
Ci stiamo tuttavia, attraverso i concetti di base di ZIPI e SKINI, sempre di più avvicinandoci alle peculiarità tecniche di OSC.

FUDI

FUDI è un protocollo di rete utilizzato internamente da Pure Data per comunicare tra il processo GUI e il processo di DSP.
Pure Data è un linguaggio di programmazione per l’audio in real time sviluppato da Miller Puckette.
PD - ZIPI, SKINI e FUDI
Lo stesso protocollo è anche usato per salvare le patch nei file di Pure Data. FUDI è l’acronimo di ‘Fast Unified Digital Interface’ (o in accordo con M. Puckette, qualunque altro acronimo).
E’ basato sull’uso di stringhe semplicissime nel quale i messaggi sono separati da un punto e virgola. I messaggi sono costituiti da blocchi separati da spazi bianchi e da blocchi numerici rappresentati sotto forma di stringhe. FUDI è un protocollo orientato a pacchetti. Ogni messaggio consiste di uno o più atom, separati da uno o più caratteri space, ed è terminato da un punto e virgola. Un atom è una sequenza di uno o piùcaratteri.
FUDI è usato con gli oggetti:
netsend/netreceive – queste classi possono essere usate per trasportare messaggi PD attraverso un TCP o un UDP socket. Entrambi sono parti della distribuzione Pd-vanilla.
netserver/netclient – queste fanno parte di maxlib e consentono connessioni bidirezionali tra multipli client e un server.
Le riflessioni riguardanti FUDI sono pressappoco quelle fatte per SKINI; ci ritroviamo di fronte a un sistema in cui la libertà operativa del ricercatore e dello studioso è massima e costituisce l’elemento principale. La sintassi è ridotta all’osso proprio per lasciare allo sviluppatore la massima autonomia. In effetti, si tratta di pochi oggetti capaci di mandare e ricevere stringhe e tutta la gestione temporale, degli indirizzi e della tipologia dei dati è affidata allo sviluppo del programmatore.

Alla prossima puntata che si occuperà del protocollo di comunicazione OSC

Maurizio Zoccola

About Maurizio Zoccola

  • Vincenzo

    Bel lavoro! Sto studiando questo argomento in Conservatorio.
    Continuate così, sono meglio degli appunti del mio prof.