Ministero dell'istruzione, dell'Università e della Ricerca CONSERVATORIO DI MUSICA
ALTA FORMAZIONE ARTISTICA E MUSICALE “Cesare Pollini”-Padova
Tesi di Diploma Accademico di 1° Livello inTECNICO DI SALA DI REGISTRAZIONE
Progettazione, Sviluppo e Verifica del Software COSB, Csound Orchestra Spatialize Builder
Diplomando: Daniele Scarano
Matricola: 00187
Relatore: Prof. Giorgio Klauer
Quest'opera è stata rilasciata con licenza Creative Commons Attribuzione 4.0 Internazionale. Per leggere una copia della licenza visita il sito web
http://creativecommons.org/licenses/by/4.0/ o spedisci una lettera a Creative Commons,
171 Second Street, Suite 300, San Francisco, California, 94105, USA.
Ringraziamenti:
Ringrazio il professor Giorgio Klauer per il sostegno nel portare a
compimento questo lavoro e per i preziosi consigli.
Ringrazio il professor Nicola Bernardini per l’importante contributo iniziale
allo sviluppo di COSB senza il quale questo progetto non avrebbe visto la
luce.
Ringrazio Ra↵aella che mi ha supportato ed accudito per tutta la durata
dei miei studi.
Ringrazio i miei genitori per la fiducia e l’amore che mi hanno dimostrato
da sempre.
Dedico questo lavoro a Rosetta che e riuscita a trasmettermi l’energia e
l’entusiasmo che mi hanno accompagnato fino ad oggi.
Sommario
Il presente lavoro nasce dall’avvicinamento alle tecnologie che consentono
di virtualizzare la dimensione spaziale del suono. Le prime teorie alla base del
moderno concetto di spazializzazione sonora risalgono agli anni ‘60 del Nove-
cento, apparentemente in ritardo rispetto al passo del progresso tecnologico
legato all’audio, ma sostanzialmente in linea con quello dell’investigazione
scientifica che correla sperimentalmente i vari aspetti fisici, fisiologici e psico-
logici di questo campo dell’esperienza. Nel corso degli anni di studio presso
il conservatorio Pollini di Padova lo scrivente ha realizzato alcuni progetti
che prevedevano l’utilizzo della dimensione spaziale del suono, constatan-
do come l’allineamento dello sviluppo pratico rispetto a quello teorico del
cosiddetto spatial hearing sia legato ai condizionamenti non solo relativi al-
l’implementazione di specifici sistemi elettroacustici e informatici ma anche ai
microcosmi delle necessita specifiche degli utenti - in questo caso artisti, com-
positori, interpreti e sviluppatori - inseriti nel quanto mai variegato contesto
della produzione musicale contemporanea, diviso tra ambizioni individuali
di commercializzazione e prassi comunitarie di sviluppo del software libero.
Accostando i concetti alla base della percezione della localizzazione sonora
a quelli legati alla ricostruzione del campo sonoro che originano dai principi
di Huygens e apparso evidente come fosse possibile operare una sintesi ot-
tenendo risultati percettivamente molto interessanti e funzionali rispetto a
un campo di applicazione relativamente ampio. Nello specifico, il progetto
COSB ha l’obbiettivo di fornire uno strumento libero e Open Source per la
creazione di opere sonore che sfruttino la virtualizzazione in modo da creare
un’esperienza realistica e immersiva superando i confini delle dimensioni dello
spazio esecutivo. Nel corso della tesi vengono presentati i presupposti teorici
e metodologici alla base dello sviluppo dello strumento cosı come i riferimen-
ti agli aspetti piu tecnici. Vengono inoltre presentati alcuni casi d’uso del
software ed e↵ettuate alcune valutazioni in merito ai possibili miglioramenti
e sviluppi preliminari alla sua libera distribuzione.
Indice
1 Introduzione 3
1.1 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Le premesse metodologiche . . . . . . . . . . . . . . . . . . . . 4
1.2.1 L’esigenza . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.2 Lo sviluppo . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 La spazializzazione . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Alcune realizzazioni software . . . . . . . . . . . . . . . . . . . 13
1.5 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 Il software 16
2.1 L’idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Creare il software . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.1 Csound . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.2 Ruby . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.3 Gtk+ . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.4 Framework . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Metodologia di sviluppo . . . . . . . . . . . . . . . . . . . . . 20
2.5 Design dell’interfaccia utente . . . . . . . . . . . . . . . . . . . 21
3 Creazione del materiale sonoro 23
3.1 Dal materiale originale al risultato . . . . . . . . . . . . . . . . 23
3.2 Orchestra CSound . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1 Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2 Calcolo del movimento di ciascun input . . . . . . . . . 25
1
INDICE 2
3.2.3 Calcolo dell’ambiente . . . . . . . . . . . . . . . . . . . 25
3.2.4 Riverbero e output audio finale . . . . . . . . . . . . . 27
4 Come si usa COSB 28
4.1 Utilizzo da riga di comando . . . . . . . . . . . . . . . . . . . 28
4.2 Panoramica dell’interfaccia . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Header values . . . . . . . . . . . . . . . . . . . . . . . 32
4.2.2 Global configuration . . . . . . . . . . . . . . . . . . . 33
4.2.3 Space configuration . . . . . . . . . . . . . . . . . . . . 34
4.2.4 Csound templates . . . . . . . . . . . . . . . . . . . . . 36
4.3 Gestione dei modelli . . . . . . . . . . . . . . . . . . . . . . . 36
4.3.1 header.orc.erb . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.2 sound source.orc.erb . . . . . . . . . . . . . . . . . . . 39
4.3.3 movements.orc.erb . . . . . . . . . . . . . . . . . . . . 40
4.3.4 point source.orc.erb . . . . . . . . . . . . . . . . . . . . 41
4.3.5 room definition.orc.erb . . . . . . . . . . . . . . . . . . 43
4.3.6 single speaker.orc.erb . . . . . . . . . . . . . . . . . . . 44
4.3.7 reverb and output.orc.erb . . . . . . . . . . . . . . . . 47
4.4 Il Generatore dell’orchestra . . . . . . . . . . . . . . . . . . . . 49
4.5 Il Generatore della partitura . . . . . . . . . . . . . . . . . . . 50
4.6 Installazione e configurazione . . . . . . . . . . . . . . . . . . 53
4.6.1 Prerequisiti . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6.2 L’installazione COSB passo passo . . . . . . . . . . . . 54
4.6.3 Prima esecuzione . . . . . . . . . . . . . . . . . . . . . 55
5 Casi di utilizzo 56
5.1 Impostazione delle verifiche . . . . . . . . . . . . . . . . . . . 56
5.1.1 Materiale audio esemplificativo . . . . . . . . . . . . . 59
5.2 Caso d’uso numero 1 . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Caso d’uso numero 2 . . . . . . . . . . . . . . . . . . . . . . . 61
6 Conclusioni 65
6.1 Valutazione dell’esperienza . . . . . . . . . . . . . . . . . . . . 65
6.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Capitolo 1
Introduzione
1.1 Struttura della tesi
Il presente lavoro si divide in sei capitoli che percorrono le fasi di progetta-
zione e realizzazione del software, a partire dall’idea iniziale fino agli sviluppi
futuri. Il primo capitolo presenta i presupposti metodologici del proget-
to e alcuni modelli applicativi di riferimento. Il secondo capitolo presenta
la tecnologia impiegata nella realizzazione del software o↵rendo una breve
panoramica sugli strumenti informatici e sul modo in cui essi sono stati im-
piegati. Il terzo capitolo descrive dettagliatamente i metodi di elaborazione
applicati al materiale sonoro per trasformarlo e aggiungergli le informazioni
spaziali. Il quarto capitolo tratta il software in maniera funzionale in forma
di manuale ed e rivolto al compositore che ne e l’utilizzatore finale e con-
temporaneamente al programmatore che voglia cimentarsi nel suo sviluppo e
miglioramento. Il quinto capitolo tratta due casi d’uso del software svolti in
forma di sessioni di test. Il sesto capitolo presenta le considerazioni scaturite
al termine del processo di ideazione, creazione e verifica del software ed una
breve analisi dell’esperienza di a�ancamento dei compositori. In conclusione
si prospettano i futuri sviluppi di questo lavoro.
3
CAPITOLO 1. INTRODUZIONE 4
1.2 Le premesse metodologiche
Scopo del lavoro e lo studio del processo creativo e di sviluppo di un software
orientato a una comunita di compositori e musicisti, quale gli studenti e
i diplomati in Musica elettronica dei Conservatori italiani. L’obbiettivo e
infatti di sperimentare la progettazione, l’implementazione e la verifica del
software nello stesso contesto dove sono state acquisite le competenze pratiche
e teoriche alla base del lavoro.
Il computer e a tutti gli e↵etti entrato a far parte della vita e delle azio-
ni quotidiane delle persone ed e sempre piu presente anche nel lavoro dei
musicisti e dei compositori. I primi esempi di utilizzo del calcolatore per la
musica risalgono agli anni ‘50 del Novecento e l’interesse dei compositori ver-
so il mondo dell’informatica puo essere collegato con la comparsa della teoria
dell’informazione di Shannon e Weaver. Inizialmente il calcolatore veniva
concepito come mezzo per simulare ricorsivamente le scelte del composito-
re avendo impostato precedentemente regole e strutture condizionali; specie
nella musica aleatoria, questo procedimento consentiva di risparmiare molto
tempo nella prassi compositiva, consentendo di predire lo sviluppo dell’opera
per poi optare per la soluzione migliore. Il calcolatore costituiva quindi un
assistente alla composizione anche nell’esecuzione di complessi calcoli che co-
stituivano potenzialmente la sostanza o il contenuto della composizione stes-
sa: si pensi soltanto a Iannis Xenakis, il quale introduceva molteplici concetti
relati alla teoria della probabilita nel calcolo della costruzione simbolica delle
sue partiture.
Dalle prime esperienze molte cose sono cambiate e lo sviluppo tecnologico
ha dato al calcolatore un ruolo centrale nella vita delle persone. L’utilizzo
costante del computer cosı come di smartphones e tablet ha reso piu compe-
tente la maggioranza delle persone compresi tutti coloro i quali si occupano
di musica; l’elemento computazionale e ormai dato per scontato e la velocita
del calcolatore non e piu percepita come tale ma interiorizzata come elemen-
CAPITOLO 1. INTRODUZIONE 5
to quotidiano. Di conseguenza ci si rivolge al computer per le azioni piu
semplici come prendere appunti durante le lezioni o tenere un calendario.
Osservando la situazione dell’alta formazione artistica e musicale e in
particolare il panorama dei corsi accademici in Musica elettronica presso i
Conservatori, si evince una comunita di compositori/musicisti che utilizza
attivamente il computer per il proprio processo creativo, e che questa comu-
nita cresce di giorno in giorno producendo altresı costantemente, nei limiti
delle proprie competenze, strumenti e software in proprio. Quest’ultima af-
fermazione trova conferma nell’abbondanza di software disponibile sul web
e scaricabile gratuitamente o a pagamento sui siti dei compositori stessi,
musicisti e tecnici del suono.
Rivolgendo lo sguardo allo specifico degli strumenti per comporre ed ese-
guire musica ci si accorge che il materiale disponibile sul web e di�cilmente
catalogabile e interpretabile senza addentrarsi nella comprensione delle esi-
genze specifiche di chi lo ha prodotto. In gran parte dei casi non e sbagliato
a↵ermare che gli strumenti disponibili in rete nascono da esigenze di un com-
positore o di un gruppo ristretto a↵erente a un singolo centro di produzione
per diventare solo in un secondo momento condivisi da comunita piu ampie,
fino a quella globale dei fruitori dell’informazione in rete. La di↵usione di
tali strumenti dipende pertanto dalla comunicazione tra chi produce gli stru-
menti e i fruitori, in canali di comunicazione sempre piu ampi, in funzione
della semplicita di utilizzo. Tuttavia sembra anche che in molti contesti non
ristretti la competenza informatica dei compositori elevi questi al rango di
sviluppatori e di conseguenza diviene opportuno porsi la questione in qual
misura sia necessario formare artisti con competenze tali da essere autonomi
nella realizzazione degli strumenti di cui hanno bisogno. Una seconda que-
stione, direttamente connessa alla precedente, riguarda la consistenza stessa
degli strumenti dedicati alla composizione e generazione dell’opera musicale.
Non e presunzione di questo studio dare una risposta argomentata a que-
sti quesiti, quanto piuttosto delineare un’immagine il piu possibile oggettiva
della problematica esemplificandola mediante un’ulteriore, personale realiz-
CAPITOLO 1. INTRODUZIONE 6
zazione rispondente a esigenze specifiche e valutata sulla base di casi d’uso.
Alla prima questione e d’altronde facile rispondere pragmaticamente, dicen-
do che che il compositore pur possedendo competenze informatiche avanzate
non deve considerarsi un informatico che si occupa di musica; e in e↵etti, i
corsi di studio in Musica elettronica e in Composizione orientata alle tecno-
logie, italiani e stranieri, come anche i centri di produzione che o↵rono un
supporto di formazione agli artisti, hanno come finalita fornire basi infor-
matiche su�cienti all’utilizzo consapevole ed esperto degli strumenti utili a
realizzare e interpretare le opere, e non a svilupparne per consentire ad altri
di farlo.
La seconda questione merita una digressione sull’innumerevole quantita
di strumenti per la composizione e la realizzazione delle opere musicali, da
applicativi come Csound e SuperCollider agli step-sequencer come Ableton
Live, Audiomulch e simili, ai software per la composizione assistita all’elabo-
ratore come Open Music, ai software per l’editoria che integrano strumenti di
ausilio alla composizione come Sibelius e Finale, fino a giungere alle piccole
utilities disponibili sul web che assolvono a compiti specifici quali le innu-
merevoli patch realizzate in Max/MSP distribuite come software standalone.
Questi strumenti possono essere divisi pertanto in tre macro categorie:
• framework di sviluppo piu o meno intuitivi o veri e propri linguaggi di
programmazione (PureData, Csound, SuperCollider)
• software musicali in cui non e previsto lo sviluppo (Ableton Live)
• patch o plugin creati con vari framework disponibili
L’artista solitamente e↵ettua una distinzione funzionale tra le tipologie e
nella maggior parte dei casi ne utilizza svariate anche per la realizzazione
di una sola opera. Le scelte dipendono sia dalle esigenze estetico-poietiche
sia dalle competenze, tuttavia l’opera risulta soprattutto dalla competenza
dell’autore accoppiata alla capacita di scegliere funzionalmente lo strumento
adeguato.
CAPITOLO 1. INTRODUZIONE 7
Osservando la quantita di strumenti disponibili in rete ci si potrebbe porre
la domanda su quanto lavoro sia implicato nella realizzazione e quanta ener-
gia venga sprecata all’interno della comunita dei musicisti e dei compositori,
per creare strumenti usa e getta impiegati per lo piu una volta per ciascuna
produzione. Tralasciando il fatto che all’interno di determinate comunita
la creazione dei propri strumenti rientri nelle consuetudini dell’artigianato
artistico e che quindi costituiscano essi stessi il prodotto di un’attivita crea-
tiva, la questione e se esista una prassi o meglio un approccio metodologico
che possa favorire lo sviluppo di strumenti piu durevoli e introducibili in
un meccanismo di di↵usione e riutilizzo al fine di valorizzarne le specificita
in un’ottica di ulteriore sviluppo e ottimizzazione, recuperando cosı quelle
energie sprecate.
L’idea emersa durante lo studio e che il sistema di condivisione e di feed-
back tipico delle comunita di sviluppatori di software open source costituisce
il miglior modello per la creazione degli strumenti utilizzati dalla comunita
dei compositori e dei musicisti. Poco importa se lo strumento nasce da una
necessita specifica di un singolo artista, nel momento in cui la necessita vie-
ne portata all’attenzione di una comunita che esprime la propria opinione
condizionando positivamente e indirizzando le scelte su come a↵rontarla e
risolverla: il beneficio collettivo supera in importanza l’esigenza del singolo
senza pero dimenticarla. La dimensione di questo studio e il limitato nume-
ro di casi studiati hanno gia consentito di rilevare alcuni benefici quali ad
esempio la diminuzione delle necessita di refactoring.
1.2.1 L’esigenza
Il software COSB vuole corrispondere all’esigenza di artisti mediamente com-
petenti in informatica musicale, di creare una spazializzazione su supporto di
composizioni acusmatiche finalizzata alla di↵usione in un’ambiente specifico
di medie dimensioni dotato di un sistema multicanale. Lo strumento dove-
va in particolare consentire di eseguire il rendering del materiale audio e di
ascoltarne il risultato durante la fase di realizzazione della composizione in
CAPITOLO 1. INTRODUZIONE 8
vista di una sessione di prove nello spazio esecutivo. Lo strumento doveva
permettere inoltre la flessibilita di ridisegnare il progetto di rendering, qua-
lora le prove nello spazio esecutivo lo avessero reso necessario; lo strumento
doveva consentire infine di poter virtualizzare una grande molteplicita di spa-
zi e sistemi di di↵usione. Per facilitare l’uso del software nelle varie fasi di
utilizzo, esso e stato dotato di un’unica interfaccia grafica che permette di
svolgere ogni funzione prevista dal software.
1.2.2 Lo sviluppo
Le tecnologie utilizzate nello sviluppo sono open source, scelta discussa am-
piamente nel secondo capitolo. Il software libero e le comunita ad esso legate,
cosı come all’open source, sono apportatori di una metodologia molto speci-
fica per quanto riguarda lo sviluppo e l’aggiornamento dei progetti; i principi
su di base possono pero venire estesi anche ad altri ambiti quali la produzione
musicale elettroacustica e mista. In primo luogo si e provato ad applicare la
metodologia di sviluppo del software libero alla fase di progettazione e rea-
lizzazione dello strumento di spazializzazione, facendo emergere i di↵erenti
approcci dello sviluppatore e dell’artista, ovvero le diverse interpretazioni
dello stesso obiettivo, ovvero la creazione di uno strumento che rispondesse
a esigenze reali. Il processo puo essere schematizzato come segue:
implementazione - test - feedback - implementazione - test - feedback. . .
Per analizzare la problematica dell’interferenza costruttiva tra artista e
sviluppatore sono state e↵ettuate due sessioni di lavoro di↵erite nel tempo,
sperimentando cosı il processo ricorsivo appena descritto. In questo caso la
presentazione del software con le sue caratteristiche e funzioni viene operata
dallo sviluppatore direttamente e senza alcun filtro. Al compositore e stato
chiesto di utilizzare il software autonomamente senza la possibilita di chiedere
suggerimenti allo sviluppatore, e di rispondere infine a un questionario di
valutazione dell’esperienza fatta. Dopo la prima sessione vengono analizzate
le risposte fornite dal compositore ed eseguite le modifiche necessarie prima
di passare alla fase di sperimentazione seguente. Secondo questo metodo
CAPITOLO 1. INTRODUZIONE 9
il raggiungimento di un risultato soddisfacente dovrebbe essere piu rapido,
come dimostrato da analoghe pratiche nell’ambito dell’industria dei video
games1.
1.3 La spazializzazione
Gli studi sulla spazializzazione del suono rivolti a indurre la percezione acu-
stica di una sorgente nello spazio riposano su due settori fondamentali di
conoscenza, ovvero:
1. i meccanismi fisiologici e psichici della trasduzione di stimoli in sensa-
zioni e infine in nozioni di localizzazione
2. i meccanismi fisici di realizzazione del campo acustico
Qualsiasi modello volto a rendere e�cace la spazializzazione discende dal-
l’enunciato per cui la percezione e semplicemente la relazione tra il soggetto
e l’oggetto, laddove il soggetto percettore riceve lo stimolo e sviluppa al-
l’interno dell’organismo determinati meccanismi a fronte degli stimoli stessi.
Cio implica quindi, nell’intento di rendere una localizzazione virtuale, una
approfondita conoscenza di questi ultimi [1].
Il tentativo di rendere artificialmente alla percezione un ambiente sonoro
con le sue caratteristiche specifiche muove dalla disponibilita di informazio-
ni sul campo sonoro e sul sistema auditivo, frutto dello studio approfondi-
to degli elementi che intervengono dal momento della produzione locale del
suono e della sua emissione fino al raggiungimento del sistema nervoso. Gli
studi a cui si fa riferimento comprendono pertanto l’acustica, la fisiologia
dell’orecchio e la psicologia della percezione degli stimoli acustici. L’acustica
fornisce la base scientifica allo studio della percezione in quanto o↵re la cono-
scenza esatta sulla produzione del suono e le sue caratteristiche. L’acustica
1In questo caso il ciclo di valutazione e sviluppo e serrato e coinvolge un gran nu-mero di persone, considerato come una popolazione rappresentativa rispetto alle attesedell’utilizzatore finale
CAPITOLO 1. INTRODUZIONE 10
Figura 1.1: Dummy Head
inoltre fornisce informazioni molto dettagliate su come l’ambiente influisca
sulla propagazione del suono, in particolare l’interazione con gli ostacoli che
frapponendosi tra sorgente e ascoltatore modificano l’evento sonoro, inclusi
i confini dell’ambiente stesso in cui si svolge il fenomeno. Per lo svolgimen-
to degli studi intorno alle caratteristiche intrinseche del suono e della sua
propagazione si formulano esperimenti ripetibili utilizzando suoni creati di-
gitalmente e sistemi di misurazione accurati. Nel caso specifico della misura
del fenomeno sonoro finalizzata allo studio della percezione acustica, alcune
tecniche sperimentali integrano i fenomeni acustici implicati dall’estensione
fisica del ricettore stesso, mediante l’utilizzo di una Dummy Head (figura
1.1).
La ricerca sugli aspetti fisici del suono consente di individuare variabili
che sono generalmente predicibili in maniera esatta. D’altro canto, poiche gli
esseri umani sono meno consistenti sia in relazione gli uni con gli altri sia in
relazione con se stessi, la divisione delle competenze tra area fisica, fisiologica
e psicologica e un aspetto fondamentale degli studi sperimentali che ricadono
CAPITOLO 1. INTRODUZIONE 11
Figura 1.2: Modello sorgente - mezzo - ricettore
nel settore della psicoacustica. In particolare, poiche la percezione concerne
sia aspetti fisiologici che psicofisici, se i primi forniscono piu facilmente un
riscontro quantitativo, i meccanismi che dominano i secondi sono in qualche
modo meno certi e meritano un discorso a parte: mentre un aspetto fisiologico
come la pressione del sangue puo essere misurato direttamente, l’investiga-
zione degli aspetti psicofisici ha a che fare con processi mentali indicando
le probabilita per cui un essere umano risponde a uno stimolo sviluppando
determinate sensazioni.
Begault [9] formula pertanto un modello dividendo la problematica relativa
alla resa percettiva della spazializzazione in due settori, il secondo dei quali
definito spatial hearing (figura 1.2).
In questo modello la sorgente e considerata come il suono nel punto da
cui si irradia, il mezzo l’ambiente con cui il suono interagisce a livello fisico
e il ricettore la risposta del sistema auditivo unita all’e↵etto che le spalle,
il torso e la testa hanno (fisicamente) sul suono. Nella prassi avviene che
ciascuna delle parti viene analizzata separatamente per poter essere simulata
in un algoritmo di virtualizzazione con controlli indipendenti.
Anche se la sorgente puo essere di varia natura, nel modello si prende in
CAPITOLO 1. INTRODUZIONE 12
considerazione una sorgente puntiforme omnidirezionale. Il contenuto della
sorgente possono essere suoni di sintesi generati da computer e suoni registrati
in camera anecoica; in entrambi i casi si fa in modo che il contenuto non
integri alcuna informazione spaziale, in quanto tali informazioni andrebbero a
sommarsi e a interferire con quelle simulate diminuendo l’e�cacia del sistema.
Durante il transito nel mezzo avvengono importanti modificazioni apporta-
trici di informazioni utili alla localizzazione della sorgente e alla comprensione
del contesto [1]. In un contesto reale si producono gli e↵etti delle riflessioni
alle pareti e del riverbero: queste consentono di desumere percettivamente le
dimensioni dell’ambiente se non addirittura le caratteristiche degli arredi [5].
Il ricettore e un essere umano a sua volta contraddistinto da caratteristiche
fisiche che vanno a modificare il campo sonoro, a cominciare dall’e↵etto del
torso e delle spalle, l’e↵etto della testa e quelli dell’orecchio esterno (padiglio-
ne auricolare e canale auditivo). Tali interferenze caratteristiche del ricettore
vengono modellizzate convenzionalmente sotto la sigla HRTF - Head Rela-
ted Transfer Functions in complessi banchi di filtri, a fianco alla piu semplice
modellizzazione delle ITD - Interaural time di↵erence e IID - Interaural inten-
sity di↵erence, utili a ricostruire la percezione rispetto alla posizione angolare
della sorgente.
Poiche il software COSB e finalizzato alla di↵usione multicanale, e stata
tralasciata l’implementazione dell’ascolto binaurale mediante HRTF, mentre
invece e stato implementato un modello con sorgenti virtuali in movimen-
to. Il modello di simulazione associa il calcolo delle mandate del segnale ai
singoli di↵usori in base alla distanza relativa (DBAP - Distance Based Am-
plitude Panning) al calcolo dei ritardi temporali, a�nando la ricostruzione
della percezione del campo sonoro modellizzando le prime riflessioni delle
sorgenti sulle pareti e il riverbero.
CAPITOLO 1. INTRODUZIONE 13
1.4 Alcune realizzazioni software
Tra gli innumerevoli applicativi sviluppati da quando i personal computer
possiedono su�cienti risorse di calcolo per la spazializzazione multicanale,
pochi contengono le caratteristiche di COSB. Generalmente, come specificato
in introduzione i progetti nascono da necessita specifiche in contesti specifici,
sovente dipendenti da uno specifico impianto di di↵usione in uno specifico
ambiente reale. Si tratta comunque di progetti importanti che producono
risultati acustici ottimi e per cui sono state disegnate interfacce d’utilizzo in
base a casi d’uso di notevolissimo contenuto qualitativo.
Un primo esempio e il software OMPrisma, di fatto una libreria per Open
Music2. La libreria contiene una serie di classi e funzioni che consentono
di spazializzare il suono estendendone le caratteristiche in modo da vir-
tualizzarne la collocazione, anche variabile, in uno spazio specifico (figura
1.3).
Un altro interessante software e il piu noto Spat sviluppato sempre all’IR-
CAM dall’Acoustic and Cognitive Spaces Team. Si tratta di uno strumento
completo che consente di spazializzare virtualizzando le caratteristiche acu-
stiche di un ambiente chiuso, estremamente accurato dal punto di vista del-
l’elaborazione del segnale. Nonostante le ottime premesse il plugin risulta
limitato a un massimo di 8 canali in uscita ed e distribuito commercialmente
a un costo piuttosto elevato (figura 1.4).
Un ulteriore esempio di software per la spazializzazione, o meglio di rico-
struzione di un campo sonoro contenenti sorgenti sonore anche in movimento,
e WFSCollider, applicativo standalone basato su SuperCollider dedicato alla
tecnica di Wave Field Syntesis. Il progetto e sviluppato da Wouter Snoei
nell’ambito della fondazione olandese Game Of Life. Il software e molto2Ambiente di composizione assistita all’elaboratore sviluppato all’IRCAM di Parigi,
finalizzato in origine alla produzione di partiture in notazione tradizionale e successiva-mente espanso e aperto all’interazione con una molteplicita di altri applicativi, specie quellifinalizzati alla sintesi modale.
CAPITOLO 1. INTRODUZIONE 14
Figura 1.3: Screenshot del software OMPrima
Figura 1.4: Screenshot del software SPAT sviluppato all’IRCAM
CAPITOLO 1. INTRODUZIONE 15
Figura 1.5: Screenshot del software WFSCollider sviluppato da Wouter Snoeiper la fondazione Game Of Life
versatile e presenta un’interfaccia intuitiva. In questo caso si tratta di un
software dedicato a impianti di di↵usione rientranti nella specifica tipologia
degli array multicanale. Il software e distribuito gratuitamente e lo sforzo
computazionale e piuttosto consistente (figura 1.5).
1.5 Conclusioni
Le premesse metodologiche forniscono il contesto in cui si inserisce la scrittura
del codice di COSB. La fase di pianificazione del progetto e molto importante
per gettare solide basi per la scrittura del codice. Consapevoli che lo sviluppo
di un software con le caratteristiche descritte puo richiedere diversi anni
abbiamo cominciato lo sviluppo con la speranza che si tratti dell’inizio di un
progetto di lunga durata. L’obbiettivo era quello di arrivare ad uno strumento
funzionante. L’obbiettivo e stato raggiunto e l’interesse degli studenti per il
software costituisce un’ottima base di partenza per gli sviluppi futuri.
Capitolo 2
Il software
2.1 L’idea
Il software COSB, acronimo di Csound Orchestra Spatializer Builder, na-
sce con l’intento di fornire al compositore uno strumento intuitivo per la
generazione di opere che utilizzino lo spazio come elemento essenziale del
linguaggio musicale1. Lo strumento e adattabile a diverse sale da concerto
con la possibilita di memorizzarne la configurazione per utilizzi successivi,
specie l’elaborazione della stessa composizione in di↵erenti sale mantenen-
do gli stessi automatismi di movimento. L’elaborazione del movimento delle
sorgenti sonore puo essere e↵ettuata basandosi su template senza dover mo-
dificare la “partitura” dei movimenti, in modo da creare sia per l’ascoltatore
che l’artista un unico spazio virtuale slegato da quello esecutivo reale incluse
le sue caratteristiche acustiche e tecniche di di↵usione. Il minimo numero di
canali necessari a ottenere l’e↵etto di spazializzazione in COSB e stato fissato
in quattro, considerando di↵usori posti approssimativamente ai vertici di un
rettangolo il cui centro e l’ideale collocazione dell’ascoltatore.
1Lo spazio viene qui inteso come area di virtualizzazione dove i suoni, nella percezionedell’ascoltatore, si muovono seguendo le indicazioni del compositore
16
CAPITOLO 2. IL SOFTWARE 17
2.2 Creare il software
COSB e un generatore di codice sorgente, quindi un programma il cui scopo
e generare altri programmi sulla base di caratteristiche predefinite o impo-
state dall’utente. In quest’ottica puo essere definito uno strumento di utilita
e pertanto presenta una serie di caratteristiche quali semplicita di utilizzo,
adattabilita a esigenze specifiche, modularita ovvero capacita di estensione
mediante nuove funzioni e comportamenti. Il nucleo attorno a cui si basa
il software e composto da una serie di script sviluppati dal professor Nicola
Bernardini al Conservatorio Pollini di Padova. In questo paragrafo si pren-
dono in considerazione le fasi di progettazione e realizzazione, scendendo nei
dettagli al fine di chiare le scelte sia tecniche che funzionali estetiche.
La costruzione dello strumento e fortemente basata sull’idea dell’indipen-
denza dell’artista in un ambito dove egli possiede adeguate competenze, spe-
cie informatiche. Per questo motivo lo strumento non ha l’ambizione di essere
completo e definitivo, ma piuttosto aperto e condivisibile, in particolar modo
nel recepimento delle istanze di una comunita di utenti interessati al tipo
di esperienza proposta. In e↵etti il progetto contiene il tentativo di un ap-
proccio comunitario alla progettazione e allo sviluppo, sulla base del modello
della comunita di musicisti competenti in informatica legati al contesto delle
Scuole di Musica elettronica dei Conservatori italiani, ed e scaturito dalla
constatazione di come, nonostante nei percorsi accademici sia previsto lo
studio sia teorico che pratico della spazializzazione, la necessita di spazializ-
zare le composizioni elettroacustiche implichi operazioni macchinose svolte
in maniera a↵atto artigianale con grave dispendio di energia.
Il modello di sviluppo e riepilogabile in pochi e semplici passaggi. Viene
individuata un’esigenza specifica. Sulla base di questa esigenza viene creato
uno strumento che risolva il problema; lo strumento viene fornito a un grup-
po di utilizzatori che restituiscono un feedback; sulla base della risposta degli
utilizzatori viene definita una serie di modifiche e aggiunte al nucleo originale
del software (in alcuni casi l’utilizzatore stesso puo decidere di implementa-
CAPITOLO 2. IL SOFTWARE 18
re modifiche per adattarlo alle proprie esigenze e proporne la condivisione
alla comunita in modo da integrarle nel pacchetto di distribuzione). Il mo-
dello si ispira apertamente alla comunita del software libero, ne recepisce i
principi fondamentali quali la condivisione e la liberta cercando di applicarli
alla ricerca lasciando in secondo piano la correzione di quello che in gergo
informatico e denominato bug.
Un altro fattore di notevole rilievo alla base di COSB e la constatazione
che gli artisti sfruttano per la creazione delle proprie opere o l’interpretazione
delle opere altrui una pletora di strumenti che si integrano vicendevolmente
quando questa possibilita e prevista nel loro sviluppo, il che avviene soven-
te nel caso di distribuzione commerciale: cio costituisce naturalmente un
problema insormontabile per una comunita volontaria.
2.3 Tecnologie utilizzate
Le tecnologie utilizzate sono tutte free (as in freedom) software o software
libero. Questo requisito consente di pubblicare il software gratuitamente uti-
lizzando una delle licenze disponibili come ad esempio la GNU GPL v2.0, e di
condividerlo quindi con le comunita di sviluppatori e musicisti che desiderino
utilizzarlo, modificarlo e redistribuirlo utilizzando a loro volta la medesi-
ma licenza con cui viene rilasciato il software originale. Altra caratteristica
comune alle tecnologie selezionate riguarda il supporto di molteplici piatta-
forme: ogni componente puo infatti essere installato e utilizzato sui sistemi
operativi piu di↵usi (GNU/Linux, Mac OSX, Windows), scelta dettata dal
desiderio di non vincolare il software a una specifica architettura e lasciare
all’utilizzatore finale la possibilita di continuare a usare il proprio sistema.
2.3.1 Csound
Csound e software libero distribuito con GNU Lesser General Public Licen-
se e sviluppato da una comunita di volontari. Si tratta di un linguaggio di
programmazione specifico per il sound design, la sintesi del suono e l’ela-
CAPITOLO 2. IL SOFTWARE 19
borazione di segnali audio. Fornisce gli strumenti per la composizione e la
performance su un ampio ventaglio di sistemi; non e ristretto ad alcun genere
musicale venendo utilizzato per la creazione di musica classica, pop, tecno,
ambient, sperimentale e naturalmente computer music. E stato utilizzato
anche per creare musica da film e per la televisione [21].
2.3.2 Ruby
Ruby e un linguaggio di scripting completamente a oggetti. Creato nel 1993
come progetto personale del giapponese Yukihiro Matsumoto, Ruby e un
linguaggio “di equilibrio e armonia”. Il suo sviluppatore ha inteso fondere
componenti dei linguaggi di programmazione preferiti fra cui Smalltalk, da
cui Ruby ha tratto la maggior parte delle proprie caratteristiche. Matsumoto
ha dichiarato piu volte di provare a “rendere Ruby naturale, non semplice”,
in un modo che rispecchia la vita2.
Il paradigma ad oggetti di Ruby e puro, come quello di Smalltalk, os-
sia ogni componente del linguaggio, dalle costanti numeriche alle classi, e
un oggetto e come tale puo possedere metodi ed ereditarli. Gli oggetti in
Ruby sono dinamici in quanto e possibile aggiungere o modificare metodi a
run-time. Il tipo di oggetto non e pertanto definito dalla classe che lo ha
istanziato, quanto piuttosto dall’insieme dei suoi metodi, o secondo la termi-
nologia abitualmente utilizzata per i linguaggi come Smalltalk, dei messaggi
a cui sa rispondere. In Ruby e dunque fondamentale il “duck typing” (if it
looks like a duck, and quacks like a duck, it must be a duck), ovvero il princi-
pio secondo cui il comportamento di una funzione rispetto ai suoi argomenti
non deve essere determinato dal loro tipo, bensı da quali messaggi essi siano
in grado di gestire [14].
2.3.3 Gtk+
Gtk+ e una libreria di widget che consente di costruire un ambiente grafi-
co per software scritti in vari linguaggi di programmazione. Anche Gtk+ e
2“Ruby e apparentemente semplice, ma al suo interno e molto complesso, proprio comeil corpo umano” (Y. Matsumoto, “Ruby-Talk”, 12 maggio 2000).
CAPITOLO 2. IL SOFTWARE 20
software libero che fa parte del progetto GNU. Sulla scelta di questa libreria
ha inciso la disponibilita di un software, Glade, che consente di disegnare
l’interfaccia partendo dagli elementi grafici per poi integrare questa con il
codice sorgente. Per definizione Glade e uno strumento RAD - Rapid Ap-
plication Development, molto utile per la fase di prototipazione cosı come
molto e�cace per la realizzazione della versione finale dell’interfaccia utente
(GUI).
2.3.4 Framework
Il framework e sostanzialmente l’ambiente di sviluppo completo di tutti i
suoi componenti. Accanto alle tecnologie descritte sono stati utilizzati altri
strumenti indispensabili alla creazione di COSB; nell’ottica del framework
la scelta delle versioni dei software da utilizzare e argomento piuttosto de-
licato a causa della velocita con cui i software vengono aggiornati e per il
fatto che le caratteristiche supportate da ciascuna versione possono di↵erire
per alcuni dettagli, come essere dismesse a favore di altre piu e�cienti. Per
controllare questi due aspetti e stato utilizzato RVM - Ruby version Mana-
ger, strumento che consente di installare piu versioni di Ruby sulla stessa
macchina e di selezionarne di volta in volta la versione desiderata; anche la
gestione delle gems, ovvero le librerie aggiuntive ed estensioni del linguaggio
Ruby, e dinamica. Con questo sistema si riesce a stare al passo con le nuove
versioni del software rilasciate durante l’intera fase di sviluppo in modo che
il software non diventi obsoleto prima ancora di essere stato terminato, come
anche fornire un supporto a quanti non dispongono di tecnologie all’ultimo
grido ma dispongono di una versione obsoleta.
2.4 Metodologia di sviluppo
Per la realizzazione di COSB e stata scelta una metodologia di sviluppo agile,
favorita dal coinvolgimento dei futuri utilizzatori nella fase di sviluppo. La
denominazione nel caso specifico e TTD - Test Driven Development (svilup-
po guidato dalle verifiche). Il metodo prevede che lo sviluppo vero e proprio
CAPITOLO 2. IL SOFTWARE 21
del software sia preceduto dalla realizzazione di test automatici. Il processo
si articola nella ripetizione di brevi cicli di sviluppo e collaudo noti come “ci-
cli TDD”: scrivendo i test prima del codice, si utilizza il programma prima
ancora che venga realizzato, assicurandosi che il codice prodotto sia testabile
singolarmente. E dunque imprescindibile una precisa visione delle modalita
di utilizzo del software prima d’essere implementato. I benefici dell’applica-
zione di questo metodo sono il minor numero di errori concettuali durante
l’implementazione; inoltre, gli sviluppatori possono permettersi di e↵ettuare
cambiamenti radicali di design certi di ottenere un programma che si com-
portera infine nella maniera prevista. Il metodo e particolarmente adatto a
COSB perche ingloba nel progetto gli sviluppi futuri - uno degli obbiettivi
del TDD e infatti il refactoring - e in secondo luogo perche impone la de-
terminazione dei requisiti del programma rivolgendo l’attenzione allo scopo
piuttosto che all’implementazione del codice.
2.5 Design dell’interfaccia utente
Nella creazione dell’interfaccia utente sono stati presi in esame alcuni con-
cetti basilari di HCI - Human Computer Interaction per procedere a scelte
coerenti con gli scopi. Il modello di interfaccia creato per COSB non presenta
particolari innovazioni; come criterio generale lo strumento e concepito come
ausilio alla composizione quindi per un’utenza piu musicale che informatica;
in secondo luogo lo strumento e destinato a utilizzatori in possesso di elevate
competenze di Csound, non indispensabili per l’uso basilare ma necessarie
per un uso avanzato nelle finalita. Tutti gli elementi fondamentali per il
funzionamento del software sono presenti nella finestra principale che si apre
avviando COSB: cio porta, nell’utilizzatore inesperto, alla curiosita di scopri-
re a cosa servono i vari elementi, mentre nell’utilizzatore esperto all’accesso
(e quindi al dominio) semplice e diretto di tutti gli elementi. In particolare si
e cercato di evitare che eventuali scoperte di annidamenti, a livello di intera-
zione grafica, non portassero a scarti o a ravvedimenti nel percorso creativo.
Quanto segue e lo schema dell’interfaccia grafica creato come linea guida per
lo sviluppo: la semplicita e una delle caratteristiche volute.
CAPITOLO 2. IL SOFTWARE 22
* Main window
mainVBox ->
title bar
menu bar
main central view hbox ->
SX
Header Form
global config
space config
Csound templates
DX
textbox
functionality
<
console message
status bar
<
Capitolo 3
Creazione del materiale sonoro
3.1 Dal materiale originale al risultato
COSB non fornisce alcuna funzionalita per la sintesi del suono ed e alimentato
da suoni creati precedentemente senza limitazioni sul metodo di produzione.
L’unico vincolo a cui l’utilizzatore deve sottostare e il formato dei file in
ingresso verso Csound. Per la lettura dei file si utilizza l’opcode soundin che
supporta i seguenti formati:
• 1 = 8-bit signed char (high-order 8 bits of a 16-bit integer)
• 2 = 8-bit A-law bytes
• 3 = 8-bit U-law bytes
• 4 = 16-bit short integers
• 5 = 32-bit long integers
• 6 = 32-bit floats
• 7 = 8-bit unsigned int (not available in Csound versions older than
5.00)
• 8 = 24-bit int (not available in Csound versions older than 5.00)
• 9 = 64-bit doubles (not available in Csound versions older than 5.00)
23
CAPITOLO 3. CREAZIONE DEL MATERIALE SONORO 24
Tutti i file audio devono essere a un canale, scelta dettata dal fatto che
ciascun flusso audio e trattato separatamente sia nella virtualizzazione del
movimento sia nel calcolo delle prime riflessioni dell’ambiente virtuale e il ri-
verbero. I prodotti delle elaborazioni vengono inserite in un bu↵er e alla fine
del rendering mixate in un file multicanale dove ciascun canale rappresenta
un di↵usore dell’impianto audio modellizzato (lo stesso procedimento avviene
per i canali del riverbero). Nella restituzione multicanale il materiale sono-
ro subisce delle modifiche nello spettro che potranno essere eventualmente
compensate applicando un’equalizzazione in fase di riproduzione.
3.2 Orchestra CSound
Compito principale di COSB e generare dinamicamente l’orchestra Csound in
dipendenza dei parametri specificati e dai template utilizzati in ogni specifico
caso. Durante l’inizializzazione vengono forniti parametri di default e un
template “global config” contenente le informazioni necessarie al linguaggio
Csound per definire il numero di suoni in input verso l’orchestra. Ulteriori
parametri vengono letti dal template “space config” (questi determinano il
numero di canali del file in uscita, il numero di canali del riverbero e le
distanze reali in metri dei di↵usori rispetto al centro dell’ambiente). Di fatto
in questo template viene definita la disposizione dell’impianto di di↵usione
reale.
3.2.1 Input
Lo strumento ha un funzionamento molto semplice e serve a leggere tutti
i file audio in ingresso e conservarli all’interno di una matrice zak (Robin
Whittle, Csound Manual, 1997, p.2457) da cui gli stream potranno essere
letti ed elaborati successivamente. Il core del template e il seguente:
asig soundin ifno
zawm asig, index
Il segnale viene letto con l’opcode soundin e salvato nella variabile za con
la precisione a-rate definita dalla frequenza di campionamento dell’orchestra.
CAPITOLO 3. CREAZIONE DEL MATERIALE SONORO 25
3.2.2 Calcolo del movimento di ciascun input
Lo strumento calcola il movimento di ciascun suono in ingresso, laddove ogni
movimento e un segmento o una posizione statica (il numero dei movimenti
non puo essere inferiore al numero dei suoni in input). Per ciascun movi-
mento viene definito un sistema cartesiano la cui origine rappresenta il punto
mediano della sala, una coppia di coordinate di partenza, una durata in milli-
secondi e una coppia di coordinate d’arrivo. Sulla base di queste informazioni
lo strumento calcola l’interpolazione lineare delle coordinate salvandola come
segnale k-rate all’interno di una matrice zk. Questo strumento si basa su un
unico template definito nel file movements.orc.erb.
3.2.3 Calcolo dell’ambiente
Questo strumento, il piu complesso del software COSB, e preposto all’ela-
borazione del materiale sonoro. Per ogni suono in ingresso definito nello
strumento input viene creato uno strumento per il calcolo dell’ambiente 1.
Per ciascun di↵usore vengono prodotti due flussi audio, il suono diretto con
le dovute variazioni di ampiezza e fase, e le prime riflessioni anch’esse con le
dovute variazioni di ampiezza e fase. Il modello teorico e il lavoro di John
Chowning The simulation of moving sound sources pubblicato per la prima
volta nel 1971 e piu volte ripubblicato. L’implementazione del simulatore
dell’ambiente e basato sul presupposto che per localizzare correttamente una
sorgente sonora in uno spazio chiuso l’ascoltatore ha bisogno di due campi
di informazione: la sua posizione angolare e le informazioni relative alla di-
stanza tra ascoltatore e sorgente. Per queste ultime e necessario, secondo
Chowning, sintetizzare il segnale diretto e il segnale riverberante mixandoli
in modo che l’attenuazione del segnale diretto aumenti maggiormente all’au-
mentare della distanza rispetto a quanto aumenta l’attenuazione del segnale
riverberante. Se l’ampiezza del segnale diretto e proporzionale all’inverso
della distanza, dando per assodato che in un ambiente di ridotte dimensioni
la variazione di intensita del segnale riverberante e trascurabile rispetto a
1Si intende l’insieme dei parametri da applicare al suono diretto per costruirel’immagine dell’ambiente virtuale.
CAPITOLO 3. CREAZIONE DEL MATERIALE SONORO 26
un ambiente di grandi dimensioni (dove varia abbastanza), in COSB il de-
cadimento dell’ampiezza del segnale riverberante e fissato nell’inverso della
radice quadrata della distanza.
; positional parameters for speaker 1
kxsp1 = kx-ixsp1
kysp1 = ky-iysp1
kxsp1q = kxsp1*kxsp1
kysp1q = kysp1*kysp1
; direct signal distance calculation
kdsp1 = sqrt(kxsp1q+kysp1q)
; dist dir -> sp1
; first order reflection distance calculations
ksp1w1 = sqrt(kxsp1q+(kw1*kw1))
; dist ref w1 -> sp1
ksp1w2 = sqrt(kxsp1q+(kw2*kw2))
; dist ref w2 -> sp1
ksp1w3 = sqrt(kxsp1q+(kw3*kw3))
; dist ref w3 -> sp1
ksp1w4 = sqrt(kxsp1q+(kw4*kw4))
; dist ref w4 -> sp1
;
; delays
kdeldsp1 port kdsp1/givel,0.1
; direct sound
kdelsp1w1 port ksp1w1/givel,0.1
; wall 1 reflection
kdelsp1w2 port ksp1w2/givel,0.1
; wall 2 reflection
kdelsp1w3 port ksp1w3/givel,0.1
; wall 3 reflection
kdelsp1w4 port ksp1w4/givel,0.1
; wall 4 reflection
CAPITOLO 3. CREAZIONE DEL MATERIALE SONORO 27
;
; signal management
adsp1 deltapi kdeldsp1
; direct signal -> sp 1
asp1w1 deltapi kdelsp1w1
; ref w1 -> sp 1
asp1w2 deltapi kdelsp1w2
; ref w2 -> sp 1
asp1w3 deltapi kdelsp1w3
; ref w3 -> sp 1
asp1w4 deltapi kdelsp1w4
; ref w4 -> sp 1
; lpf filter on back wall reflections
alpfsp1w3 tone asp1w3, iw3cutoff
;
asp1 = ((adsp1/kdsp1)+
(asp1w1/ksp1w1)+
(asp1w2/ksp1w2)+
(asp1w3/ksp1w3)+
(asp1w4/ksp1w4))
;
arevsp1 = asp1*iattarev*(1/sqrt(kdsp1))
; reverb on sp 1
3.2.4 Riverbero e output audio finale
Per ottenere la qualita desiderata della di↵usione del suono e l’e↵etto di “av-
volgimento” realistico nell’ascoltatore, per ciascun altoparlante si calcola un
riverbero aggiuntivo di ampiezza e ritardo specifico relativo alla posizione del-
la sorgente. Lo strumento in questione rappresenta la fase conclusiva della re-
stituzione sonora e si occupa, oltre che dell’applicazione del suono riverberato
alla mandata verso ciascun di↵usore, anche di scrivere i file multicanale.
Capitolo 4
Come si usa COSB
COSB e principalmente uno strumento compositivo in quanto le funzioni
di spazializzazione non si sviluppano in tempo reale. Un prerequisito fonda-
mentale e la conoscenza di Csound senza la quale e impossibile comprendere
il software. Un altro prerequisito e una conoscenza di base dell’uso del termi-
nale. L’interfaccia grafica costruita come un editor fornisce la possibilita di
apportare modifiche al codice Csound generato e ai templates utilizzati per
la generazione. In entrambi i casi per eseguire correttamente le modifiche
e necessario capire a fondo sia la logica del software che il codice Csound:
nelle pagine successive vengono pertanto presentate tutte le parti modifica-
bili dall’utente partendo dai parametri di configurazione fino ad arrivare alla
modifica dei templates del generatore di codice.
4.1 Utilizzo da riga di comando
Il core del software COSB e il renderer scritto in Ruby ed e possibile utilizzare
il generatore di codice direttamente dalla riga di comando. L’output del
rendering viene indirizzato sullo standard output del terminale oppure scritto
in un file. L’utilizzo e quello tipico dei comandi Unix con alcuni flag che
modificano le opzioni di rendering e consentono di caricare dei templates
diversi da quelli di default. Il listato che segue contiene l’aiuto in linea del
software che si ottiene digitando sul terminale il comando ‘cosb -h’.
28
CAPITOLO 4. COME SI USA COSB 29
cosb is a generator of orchestra instruments for csound to run
spatial simulations for any kind of location and any
technological setup (from mono to stereo to multichannel to
high-order ambisonics). +cosb+ reads a configuration file for
the physical location, the setup and the virtual location and
create the appropriate orchestra instruments in order to play
with the wanted space.
Usage: cosb [options]
$ cosb -h
Options are:
-s, --space FILE Use space configuration
Default: default.yml
-g, --global FILE Use global configuration
Default: default.yml
-i, --sound-input TEMPLATE Use sound input template
Default: sound_source.orc.erb
-m, --movements TEMPLATE Use movements template
Default: movements.orc.erb
-r, --reverb-and-output TEMPLATE Use reverb and output template
Default: reverb_and_output.orc.erb
-h, --help Show this help message.
Lanciando semplicemente ‘cosb’ viene generato il codice csound con i tem-
plate caricati di default e il codice sorgente viene visualizzato sullo standard
output del terminale.
CAPITOLO 4. COME SI USA COSB 30
Figura 4.1: Interfaccia grafica come appare all’avvio
4.2 Panoramica dell’interfaccia
L’interfaccia e disegnata per definire tutte le impostazioni necessarie al ren-
dering. L’utilizzatore ha accesso immediato a tutti i parametri di configu-
razione richiesti da Csound, accanto ai quali si trovano i parametri per la
spazializzazione, il numero di sorgenti audio utilizzate, il numero di canali
in uscita, il tempo di riverbero e altri. I parametri possono essere modificati
attraverso i form oppure attraverso l’editor fornito nel software che consente
di modificare direttamente i file di configurazione. In figura 4.1 l’interfaccia
come appare all’avvio.
Sul lato sinistro e visibile il form con la configurazione; i parametri sono
suddivisi in quattro gruppi:
• Header Values
• Global Configuration
• Space Configuration
CAPITOLO 4. COME SI USA COSB 31
Figura 4.2: Files che saranno utilizzati per il rendering
Figura 4.3: Dettaglio del form del singolo template
• Csound Templates
La parte destra e un’area di editing che consente di visualizzare il con-
tenuto dei file. L’editor di testo possiede funzioni basilari per modificare i
file di configurazione, i template e il codice Csound generato. Nella parte
inferiore della finestra si trova la console che visualizza gli errori e i messaggi
informativi delle funzioni utilizzate. Al momento le funzionalita sono mini-
me, ma il design dell’interfaccia e pensato per essere modulare e arricchito
di ulteriori possibilita.
Per ciascun file le operazioni consentite sono la visualizzazione del con-
tenuto nell’editor con il tasto “view”, la scelta di template diversi tramite
il tasto “load” e infine un tasto “default” che ripristina la configurazione
fornita nel pacchetto di installazione.
Una volta visualizzato il contenuto di uno dei file di configurazione o di
uno dei template l’utente ha la possibilita di modificarne il contenuto e di
CAPITOLO 4. COME SI USA COSB 32
Figura 4.4: Dettaglio del form Header Values
salvare il file con le modifiche. Nell’area dell’editor e possibile visualizzare
una preview del codice Csound che verra generato prima che questo venga
salvato in un file. Il nome di default del file di output e cosbOrchestra.csd.
4.2.1 Header values
Questi sono i valori impostati all’inizio dell’orchestra Csound, accanto ad
altri valori come il numero dei bus audio per la generazione degli strumenti.
sample rate: frequenza di campionamento del programma Csound e del-
l’output audio;
ksmps: numero di campioni in un ciclo di controllo [7];
audio sources: numero di sorgenti utilizzate nella partitura;
simultaneous movements: numero di movimenti simultanei (questo valo-
re deve essere almeno uguale al numero di sorgenti);
reverb decay: tempo di decadimento del riverbero (RT60);
channels number: canali del file audio generato dal codice Csound. 1
1Questo numero e pari a due tracce per ogni speaker: una contiene il segnale diret-to e l’altra il segnale riverberato, separazione utile per la gestone del mix durante lariproduzione nello spazio esecutivo.
CAPITOLO 4. COME SI USA COSB 33
4.2.2 Global configuration
Si tratta del file in cui sono contenuti i parametri di configurazione globale.
Il template presentato e in formato yml [23], un linguaggio per la creazione
di template in formato comprensibile alla lettura. Ogni parametro e seguito
dai due punti ed e consentita la nidificazione.
# The <tt>global configuration</tt>
# concerns all the global parameters that
# are required while creating a csound
# spatialization score. That is:
# * sampling rate
# * ksmps
# * number of audio sources required
# * number of simultaneous movements required
# * number of point sources per wide volume object
# The +default+ file is the file loaded
# if no other file is specified
global:
sample_rate: 96000
ksmps: 100
audio_sources: 100
simultaneous_movements: 100
points_per_w_object: 13
L’utente ha la possibilita di cambiare tutti i parametri visibili generando
uno spazializzatore che rispecchia le sue esigenze. Al momento del salva-
taggio il file generato potra assumere un nome qualsiasi mentre l’estensione
dovra essere “yml”. Il parametro “audio sources” puo assumere come valore
massimo 299: questo limite e determinato dall’implementazione di COSB.
CAPITOLO 4. COME SI USA COSB 34
4.2.3 Space configuration
Questo file, come il precedente in formato yml [23], definisce lo spazio virtuale e
contiene la posizione degli altoparlanti del sistema audio target, le dimensioni
dell’ambiente virtuale utilizzato per il calcolo delle prime riflessioni e il tempo
di decadimento del riverbero. Quello presentato qui e il file di configurazione
di default, che implementa una soluzione multicanale per l’auditorium del
conservatorio “C. Pollini” di Padova.
CAPITOLO 4. COME SI USA COSB 35
The auditorium of the Conservatorio ‘‘C. Pollini’’ in Padova
is a physical space which measures approx 22 m in width
and 45 m in depth. It posseses a 9.2 spatialization system
which may be mapped as an 8 channel or 9 channel
(with a central cluster). Loudspeaker numbering leaves
all odd speakers to the left of the public (1, 3, 5, 7)
and all even speakers to the right (2, 4, 6, 8) and
speaker 9 front center.
space:
identifier: Pollini 9 channels
loudspeaker\_positions:
1: [ -9.5, 20, ’l’ ]
2: [ 9.5, 20, ’r’ ]
3: [ -11, 8, ’l’ ]
4: [ 11, 8, ’r’ ]
5: [ -11, -8, ’l’ ]
6: [ 11, -8, ’r’ ]
7: [ -9.5, -18, ’l’ ]
8: [ 9.5, -18, ’r’ ]
9: [ 0, 20, ’c’ ]
virtual\_space:
width: 30
depth: 60
reverberation\_decay: 2.3
CAPITOLO 4. COME SI USA COSB 36
Anche in questo caso il compositore al momento del salvataggio potra
attribuire un nome qualsiasi al file, ma dovra mantenere l’estensione “yml”.
4.2.4 Csound templates
I templates contengono le parti fisse di codice Csound utilizzate dal generato-
re per creare l’orchestra. Per questa parte del codice viene usata la libreria di
Ruby ERB [13], con cui e possibile creare file contenenti parti di testo statiche
e parti valorizzate eseguendo il codice Ruby compreso nei tag ERB.
4.3 Gestione dei modelli
La gestione dei template e dei file di configurazione e una delle funzionalita
principali di COSB e per questo motivo l’interfaccia grafica richiama un edi-
tor di testo. Il riquadro di sinistra fornisce l’accesso a tutto il codice sorgente
utilizzato per la generazione dell’orchestra ed e possibile visualizzare e mo-
dificare ogni file di configurazione e ogni template. Lo scopo e incoraggiare
l’utente/artista a scrivere il proprio codice Csound nella forma dei template
utilizzati da COSB per poter generare un’orchestra diversa da quella di de-
fault. Per esempio qualcuno potrebbe desiderare un altro riverbero rispetto
a quello utilizzato nel template di default, oppure potrebbe implementare dei
movimenti non rettilinei basati sulle curve di Bezier: per fare questo dovreb-
be implementare dei template appositi e il codice di COSB e stato scritto
per consentire questo tipo di interventi.
COSB di default si avvale di 7 template:
1. header.orc.erb
2. sound source.orc.erb
3. movements.orc.erb
4. point source.orc.erb
5. room definition.orc.erb
CAPITOLO 4. COME SI USA COSB 37
6. single speaker.orc.erb
7. reverb and output.orc.erb
Prima di esaminare i singoli template e necessario spiegare il funzionamen-
to della parametrizzazione2. Quello utilizzato e un sistema di valorizzazione
automatica dei template basato sulla classe ERB di Ruby. La classe consente
di eseguire e se opportuno visualizzare il risultato di codice Ruby all’interno
di un file contenente testo standard. Segue un breve esempio per chiarire il
concetto. Si Scrive un semplice template e lo si salva nel file template.erb:
My name is <%= name %>
si scrive il codice Ruby per gestire il template e lo si salva nella stessa
directory del template chiamandolo template.rb:
fh = File.open(template_name.erb)
lines = fh.readlines
template_name = lines.join
name = Daniele
template_render = ERB.new(template_name)
output = template_render.result
puts output
Quando si eseguira il file Ruby appena creato comparira a video la scritta
“My name is Daniele”; questa viene generata dall’oggetto ERB il quale legge
il template e valorizza la variabile name per visualizzarla nel testo generato.
ERB gestisce due modalita: la prima esegue il codice e lo visualizza; la
seconda lo esegue. All’interno di un template le due modalita appaiono come
nell’esempio che segue:
2Questa parte e dedicata ad alcuni concetti piu informatici che musicali, ma eindispensabile per la lettura dei template e la comprensione di COSB.
CAPITOLO 4. COME SI USA COSB 38
<% "ERB esegue il codice scritto qui" %>
<%= "ERB esegue e visualizza il risultato" %>
Questo tipo di stringhe sara presente in tutti i template ed e il cuore
della generazione del codice Csound. Per una trattazione tecnica completa e
opportuno consultare la documentazione u�ciale di ERB [13].
4.3.1 header.orc.erb
Nel template header.orc.erb vengono inizializzate le variabili fondamentali
per il funzionamento di una qualsiasi orchestra Csound.
sr = <%= cr.configuration.
\global_configuration.sample_rate %>
ksmps = <%= cr.configuration.
\global_configuration.ksmps %>
nchnls = <%= cr.configuration.
\space_configuration.num_channels %>
givel init 344 ; speed of sound at normal temperatures
zakinit <%= cr.number_of_zak_a_variables %>,
<%= cr.number_of_zak_k_variables %>
Per chi e pratico di Csound le prime tre variabili sr, ksmps ed nchnls non
saranno una sorpresa, mentre una breve descrizione e necessaria per le due
righe successive. La variabile givel, come si legge nel commento, riporta la
velocita del suono a temperatura normale; questo valore viene inizializzato
per tutti gli strumenti ed e fondamentale per il calcolo dei ritardi da applicare
ai suoni di ogni di↵usore.
L’istruzione zakinit serve a inizializzare la matrice zak, una matrice bi-
dimensionale in cui sono contenuti due tipi di informazioni: vettori letti a
CAPITOLO 4. COME SI USA COSB 39
velocita k-rate e vettori letti a velocita a-rate. Questo opcode e utile per
gestire il patching e il routing tra uno strumento e un altro in maniera fles-
sibile. Il sistema e simile a una patchbay di un mixer o a una matrice di
modulazione in un sintetizzatore. E’ generalmente molto utile per gestire
una matrice di variabili [7].
Il sistema zak viene utilizzato per entrambi gli scopi definiti dal manuale
Csound. Viene utilizzato per lo stoccaggio dei vettori che determinano il
movimento delle sorgenti nell’area di memoria dedicata alle variabili k-rate e
viene utilizzato per registrare i suoni elaborati e mixarli insieme nella parte
di memoria dedicata ai vettori a-rate.
4.3.2 sound source.orc.erb
Il template che gestisce le sorgenti, costituite da file mono salvati in uno dei
formati leggibili dall’opcode soundin, contiene l’intero codice dello strumento
input.
instr <%= cr.input_instrument_numbers %>
ifirst init <%= cr.first_input_instrument %>
index init p1 - ifirst ; audio channel (mono)
iamp = ampdb(p4)
idur = p3
ifno = p5
asig soundin ifno
asig = asig * iamp
asig linen asig, 0.005, idur, 0.005
zawm asig, index
endin
Si tratta di un semplice strumento che legge i file in input e li salva nel
sistema zak in modo da poterli recuperare nel momento dell’elaborazione
CAPITOLO 4. COME SI USA COSB 40
audio senza dover leggere il file originale. L’istruzione che consente di salvare
i file nel sistema zak e zawm : questo opcode scrive un messaggio in a-rate
nella matrice zak all’indice specificato dalla variabile index e lo somma al
valore precedente qualora siano gia presenti dei dati.
4.3.3 movements.orc.erb
Questo template contiene il codice per la generazione dello strumento move-
ments, funziona interamente in k-rate e legge dalla partitura la definizione dei
movimenti di ciascuno strumento in input. Per definire una sorgente ferma
e necessario inserire in partitura la posizione della sorgente con le coordi-
nate (x,y), la durata in secondi in cui la sorgente suonera e poi ripetere la
posizione iniziale immettendo le stesse coordinate.
instr <%= cr.list_numbers(301, 301 +
cr.configuration.global
\_configuration.simultaneous_movements) %>
ifirst init 301
index init p1 - ifirst
iparoffset init index * 2
ixindex init iparoffset ; x of { x, y }
iyindex init iparoffset + 1 ; y of { x, y }
idur = p3
ixstart = p4
ixend = p5
iystart = p6
iyend = p7
idursmps = int(idur*kr)
idurfinal = idursmps/kr
kx line ixstart, idurfinal, ixend
ky line iystart, idurfinal, iyend
CAPITOLO 4. COME SI USA COSB 41
zkw kx, ixindex
zkw ky, iyindex
endin
Come per lo strumento precedente anche questo legge dalla partitura e
scrive le informazioni nella matrice zak, ma in questo caso le informazioni
sono scritte in k-rate e divise in due vettori complementari, uno contenente
i valori in x e uno in y.
4.3.4 point source.orc.erb
Questo template genera lo strumento che gestisce il calcolo dell’ambiente.
instr <%= cr.point_source_instrument_numbers %>
; input indexings
ifirst init <%= cr.first_point_source_instrument %>
; first instrument number
index init p1 - ifirst ; audio channel (mono)
iparoffset init index * 2 ; data structure is { x, y }
ixindex init iparoffset
iyindex init iparoffset + 1
print p1, index, ixindex, iyindex
idur = p3
iattadir = ampdb(p4)
; amplitude attenuation (in dB)
iattarev = ampdb(p5)
; reverb send attenuation
; audio input
arcv zar index ; signal
CAPITOLO 4. COME SI USA COSB 42
audioin = arcv * iattadir
asend = 0
zacl index,index ; clear signal after reading
; position (coming from the movement engines)
kx zkr ixindex
ky zkr iyindex
; inner and outer room definitions
ideltaf init 20000
; should be around the threshold of hearing
<%= cr.room_definition %>
; front/back filtering
kfbfc = ideltaf * (1 + (ky/iy))
afiltered tone audioin, kfbfc
audio = (ky >= 0 ? audioin : afiltered)
; first-order reflection positions (clock-wise order)
kxmax = 2*(ixmax-kx)
kymax = 2*(iymax-ky)
kxmin = 2*(kx-ixmin)
kymin = 2*(ky-iymin)
kw1 = ky + kymax ; reflection from front wall
kw2 = kx + kxmax ; reflection from right wall
kw3 = kymin - ky ; reflection from back wall
kw4 = kxmin - kx ; reflection from left wall
kw1sq = kw1*kw1
kw2sq = kw2*kw2
kw3sq = kw3*kw3
CAPITOLO 4. COME SI USA COSB 43
kw4sq = kw4*kw4
adeld delayr 1
; maximum delay: 1 second (more than enough)
<%= cr.point_sources %>
delayw audio
endin
Si dimostra ora un comportamento di↵erente del template partendo dalle
istruzioni che lo determinano:
<%= cr.room_definition %>
<%= cr.point_sources %>
Queste due istruzioni vanno a richiamare altri due template, la prima
il file room definition.orc.erb e la seconda il template single speaker.orc.erb,
richiamato ricorsivamente tante volte quanti sono gli speaker.
4.3.5 room definition.orc.erb
Questo template costruisce tutte le informazioni relative agli ambienti reale
e virtuale.
<% cr.configuration.space_configuration.
loudspeaker_positions.each do |sp| %>
ixsp<%= sp.number %> init <%= sp.x %>
; x coordinate (in m) for speaker n. <%= sp.number %>
iysp<%= sp.number %> init <%= sp.y %>
; y coordinate (in m) for speaker n. <%= sp.number %>
<% end %>
CAPITOLO 4. COME SI USA COSB 44
; outer room definition
ixmax init <%= cr.configuration.space_configuration.
virtual_space.width.to_f / 2.0 %>
ixmin init <%= -(cr.configuration.space_configuration.
virtual_space.width.to_f / 2.0) %>
iymax init <%= cr.configuration.space_configuration.
virtual_space.depth.to_f / 2.0 %>
iymin init <%= -(cr.configuration.space_configuration.
virtual_space.depth.to_f / 2.0) %>
ix init ixmax
iy init iymax
; cut off frequency for the back wall reflections
iw3cutoff init ideltaf / (1 - (iymin*0.35))
print ixmax, ixmin, iymax, iymin, iw3cutoff
Come si nota dal sorgente non si tratta di uno strumento standalone ma
di una parte di codice riutilizzabile in altri strumenti. Qui vengono definite le
posizioni reali in metri dei singoli speaker presenti nella sala e le dimensioni
dell’ambiente virtuale generato da COSB.
4.3.6 single speaker.orc.erb
Questo template contiene la definizione di ciascuno speaker e una serie di
altri elementi fondamentali al calcolo della spazializzazione.
; output index parameters for speaker <%= s.number %>
idiroutput<%= s.number %> init <%= s.direct_output_bus %
irevoutput<%= s.number %> init <%= s.reverb_output_bus %>
; positional parameters for speaker <%= s.number %>
CAPITOLO 4. COME SI USA COSB 45
kxsp<%= s.number %> = kx-ixsp<%= s.number %>
kysp<%= s.number %> = ky-iysp<%= s.number %>
kxsp<%= s.number %>q = kxsp<%= s.number %>
*kxsp<%= s.number %>
kysp<%= s.number %>q = kysp<%= s.number %>
*kysp<%= s.number %>
; direct signal distance calculation
ksp<%= s.number %>d = sqrt(kxsp<%= s.number %>q+kysp
<%= s.number %>q) ; dist dir -> sp<%= s.number %>
; first order reflection distance calculations
ksp<%= s.number %>w1 = sqrt(kxsp<%= s.number %>q+kw1sq)
; dist ref w1 -> sp<%= s.number %>
ksp<%= s.number %>w2 = sqrt(kxsp<%= s.number %>q+kw2sq)
; dist ref w2 -> sp<%= s.number %>
ksp<%= s.number %>w3 = sqrt(kxsp<%= s.number %>q+kw3sq)
; dist ref w3 -> sp<%= s.number %>
ksp<%= s.number %>w4 = sqrt(kxsp<%= s.number %>q+kw4sq)
; dist ref w4 -> sp<%= s.number %>
; delays
kdelsp<%= s.number %>d port ksp<%= s.number %>d/givel,0.1
; direct sound
kdelsp<%= s.number %>w1 port ksp<%= s.number %>w1/givel,0.1
CAPITOLO 4. COME SI USA COSB 46
; wall 1 reflection
kdelsp<%= s.number %>w2 port ksp<%= s.number %>w2/givel,0.1
; wall 2 reflection
kdelsp<%= s.number %>w3 port ksp<%= s.number %>w3/givel,0.1
; wall 3 reflection
kdelsp<%= s.number %>w4 port ksp<%= s.number %>w4/givel,0.1
; wall 4 reflection
; signal management
asp<%= s.number %>d deltapi kdelsp<%= s.number %>d
; direct signal -> sp <%= s.number %>
asp<%= s.number %>w1 deltapi kdelsp<%= s.number %>w1
; ref w1 -> sp <%= s.number %>
asp<%= s.number %>w2 deltapi kdelsp<%= s.number %>w2
; ref w2 -> sp <%= s.number %>
asp<%= s.number %>w3 deltapi kdelsp<%= s.number %>w3
; ref w3 -> sp <%= s.number %>
asp<%= s.number %>w4 deltapi kdelsp<%= s.number %>w4
; ref w4 -> sp <%= s.number %>
alpfsp<%= s.number %>w3 tone asp<%= s.number %>w3, iw3cutoff
; lpf filter on back wall reflections
asp<%= s.number %> = ((asp<%= s.number %>d/
ksp<%= s.number %>d)+
(asp<%= s.number %>w1/ksp<%= s.number %>w1)+
CAPITOLO 4. COME SI USA COSB 47
(asp<%= s.number %>w2/ksp<%= s.number %>w2)+
(asp<%= s.number %>w3/ksp<%= s.number %>w3)+
(asp<%= s.number %>w4/ksp<%= s.number %>w4))
arevsp<%= s.number %> = iattarev*((asp<%= s.number %>d/
sqrt(ksp<%= s.number %>d))+(asp<%= s.number %>w1/
sqrt(ksp<%= s.number %>w1))+(asp<%= s.number %>w2/
sqrt(ksp<%= s.number %>w2))+(asp<%= s.number %>w3/
sqrt(ksp<%= s.number %>w3))+(asp<%= s.number %>w4/
sqrt(ksp<%= s.number %>w4)))
zawm asp<%= s.number %>, idiroutput<%= s.number %>
zawm arevsp<%= s.number %>, irevoutput<%= s.number %>
I commenti nel codice suggeriscono la funzione delle parti. Si puo notare
la presenza di tutte le informazioni relative alla spazializzazione vera e propria
e la generazione degli stream audio che costituiscono l’elaborazione dei file in
input. Le formule qui utilizzate sono riprese dal lavoro di Chowning [4], ma e
possibile modificarle per ottenere e↵etti diversi da quelli di default.
4.3.7 reverb and output.orc.erb
Questo e l’ultimo template nel processo di elaborazione dei suoni in input e
anche l’ultimo step prima della generazione del file multicanale. A guidare la
generazione e il numero di speaker presenti nell’ambiente reale, che determina
il numero delle tracce in uscita. Verra qui generato un file wav multicanale
che conterra un numero di canali doppio rispetto al numero degli speaker,
perche per ciascuno speaker verra prodotto un file contenente il suono diretto
mixato alle prime riflessioni e un altro contenente solo il riverbero. Questa
soluzione e stata pensata per dare liberta al regista del suono nel gestire il
bilanciamento tra suono diretto e suono riverberato, in funzione dell’acustica
dell’ambiente, degli arredi e del pubblico.
instr <%= Cosb::CsoundRenderer::DEFAULT_REVERB_INSTRUMENT %>
CAPITOLO 4. COME SI USA COSB 48
irevtc init <%= ruby.code %>
irevtl init irevtc-0.05
irevtr init irevtc+0.05
iatl = 0.921
; attenuation f_acute left
iatr = 0.919
; attenuation f_acute right
iatc = 0.920
; attenuation f_acute center
isiglp = 4000
; low-pass filtering of input signal
<% cr.configuration.space_configuration.
loudspeaker_positions.each do |sp| %>
; channel <%= sp.number %>
idirbus<%= sp.number %> init <%= sp.direct_output_bus %>
irevbus<%= sp.number %> init <%= sp.reverb_output_bus %>
adir<%= sp.number %> zar idirbus<%= sp.number %>
arevsend<%= sp.number %> zar irevbus<%= sp.number >
arssp<%= sp.number %> butterlp arevsend<%= sp.number %>
arev<%= sp.number %> nreverb arssp<%= sp.number %>,
irevt<%= sp.lrc %>,
iat<%= sp.lrc %>
zacl idirbus<%= sp.number %>, idirbus<%= sp.number %>
zacl irevbus<%= sp.number %>, irevbus<%= sp.number %>
<% end %>
CAPITOLO 4. COME SI USA COSB 49
; final output stage
outc <%= cr.final_output_stage %>
endin
4.4 Il Generatore dell’orchestra
Il software COSB viene equipaggiato con un set standard di template per il
codice Csound e con due file di configurazione senza i quali non sarebbe pos-
sibile generare il codice. Per creare i due file di configurazione global config e
space config sono state utilizzate le informazioni disponibili sull’auditorium
del conservatorio “C. Pollini” di Padova. Scaricando il software e installan-
dolo sul proprio computer e pertanto possibile generare di default un’orche-
stra che esegua il rendering di uno o piu file audio da riprodurre attraverso
l’impianto di questo specifico luogo.
L’orchestra generata contiene al suo interno quattro strumenti tutti colle-
gati tra loro.
1. strumento input
2. strumento movements
3. strumento point source
4. strumento reverb and output
I quattro strumenti elencati non sono indipendenti l’uno dall’altro e per
poter funzionare l’orchestra li deve contenere tutti. Lo strumento input leg-
ge i file audio definiti dal compositore e li memorizzarli nella matrice zak.
Lo strumento movements legge i movimenti di ogni sorgente e li memorizza
nella matrice zak. Lo strumento point source legge dalla matrice zak l’audio
input e i movimenti associati e calcola i ritardi sul segnale diretto e le prime
riflessioni; l’audio elaborato viene salvato nuovamente nella matrice zak. Lo
CAPITOLO 4. COME SI USA COSB 50
strumento reverb and output legge la matrice zak dopo l’elaborazione esegui-
ta dallo strumento point source e crea una traccia audio per ogni di↵usore
mixando tutte le sorgenti definite e una traccia di riverbero per ogni di↵usore
calcolando il riverbero sul missaggio delle sorgenti.
4.5 Il Generatore della partitura
L’ultimo elemento indispensabile per la generazione del materiale sonoro e
la partitura, ed essendo Csound il linguaggio del codice generato la partitu-
ra sara scritta come richiesto dal linguaggio. Per ciascuna sorgente bisogna
pertanto definire i diversi tipi di strumento (input, movimento e ambiente).
Lo strumento per riverbero e output e diverso dagli altri, venendo richiama-
to una volta sola per calcolare i segnali audio relativi a ciascuna sorgente.
L’esempio che segue riporta una partitura per una sola sorgente:
; Strumento input
; Instr/idx start dur amp ifno
i 1 0.000 10.000 1 1
; Strumento per calcolo del movimento
; instr/idx start dur ixstart ixend iystart iyend
; Strumento per il calcolo della stanza
; instr/idx start dur dBatt dBrevAtt
i 1301 0.000 10.000 0 0
;
; Riverbero e output audio finale
; instr/idx start du
i 5000 0.000 10.000
Segue l’elenco dei parametri con una breve descrizione.
• instr/idx: numero dello strumento che corrisponde all’indice del sistema
zak in cui il file viene tenuto in memoria
CAPITOLO 4. COME SI USA COSB 51
• start: inizio della presenza del file nel brano3
• dur: durata entro cui questo strumento suonera
• amp: ampiezza dello specifico strumento
• ifno: numero del file soundin di riferimento4
La sezione degli strumenti per il calcolo del movimento presenta una serie
di parametri, alcuni dei quali identici a quelli per la sezione input. I parametri
specifici sono pertanto i seguenti.
• ixstart: valore della x all’inizio del movimento
• ixend: valore della x all’arrivo del movimento
• iystart: valore della y all’inizio del movimento
• iyend: valore della y all’arrivo del movimento
La sezione dedicata al calcolo dell’ambiente presenta due nuovi parametri
specifici.
dBatt: attenuazione del segnale diretto
dBrevAtt: attenuazione del segnale riverberato
La sezione della partitura relativa al riverbero non aggiunge alcun nuovo
parametro. Una precisazione importante e che lo strumento reverb and out-
put definisce la durata complessiva del file generato, pertanto se la durata e
minore della somma di tutti i movimenti definiti l’audio risultera troncato.3Zero indica l’inizio del brano.4Consultare soundin nella documentazione u�ciale di Csound.
CAPITOLO 4. COME SI USA COSB 52
Figura 4.5: Prototipo per il generatore della partitura
CAPITOLO 4. COME SI USA COSB 53
Per la generazione grafica della partitura e stato creato un prototipo di tool
in ambiente Max/MSP (figura 4.5). Il prototipo e↵ettua la creazione della
partitura per movimenti rettilinei, gli stessi implementati nello strumento
“room” descritto precedentemente. Nel prototipo e possibile impostare il
numero di strumenti disponibili e identificarli attraverso un colore diverso,
specificabile dall’utente. Per la gestione dei movimenti e necessario imposta-
re l’istante di inizio in secondi (dove 0 indica l’inizio del brano) e la durata
di ciascun movimento. L’output viene salvato in memoria in modo da po-
terlo richiamare ed eventualmente modificare; al termine della creazione del
movimento viene generato un file .sco utilizzabile direttamente con Csound.
4.6 Installazione e configurazione
L’installazione di COSB e interamente manuale e richiede che venga seguito
un preciso ordine. Il meccanismo prevede il download del software diretta-
mente dal repository git u�ciale [22] e il lancio di alcuni comandi che creano la
struttura delle directory che conterra l’applicazione. Durante l’installazione
viene generata anche la documentazione del software. La versione scarica-
bile e installabile e unica e comprende tutto il necessario per l’utilizzo e lo
sviluppo (chi volesse leggere i sorgenti per modificarli deve fare riferimento
a questa versione).
4.6.1 Prerequisiti
Per far funzionare COSB e necessario installare sul proprio computer alcuni
software. Prima di tutto l’interprete Ruby e il gestore di pacchetti rubygem
(gem); la gem Bundler che si occupera della configurazione del software e la
gem Rake che si occupa di installare tutte le dipendenze di COSB come anche
della generazione della documentazione. Di seguito sono elencati i software
prerequisiti con le versioni di riferimento.
• Ruby 1.9.2 / 2.0.0
• Rubygem 1.3.6
CAPITOLO 4. COME SI USA COSB 54
• Bundler 1.3.5
• Rake 10.1.0
• X windows system (per i sistemi diversi da linux)
• Git, un sistema di change management (facoltativo)
4.6.2 L’installazione COSB passo passo
Il pacchetto Ruby per la propria piattaforma deve essere una delle due ver-
sioni indicate nella lista dei prerequisiti. Una volta installato Ruby bisogna
individuare il pacchetto rubygem corretto e installarlo. Dopo l’installazione
di rubygem bisogna lanciare il seguente comando:
gem install bundler
Il comando installera automaticamente bundler sul computer; per instal-
lare tutte le dipendenze necessarie all’utilizzo di bundler bisogna lanciare il
comando:
bundle install
terminata questa operazione bisogna scaricare COSB dal repository Gi-
tHub come zip e decomprimerlo in una cartella, posizionarsi nella cartella
dove e stato scompattato e lanciare il comando
rake install
oppure l’installazione per gli sviluppatori
rake newb
Entrambi questi comandi installano tutte le gem necessarie al software
COSB definite nel file Gemfile che si trova all’interno del pacchetto di instal-
lazione: in questo modo l’installazione viene parzialmente automatizzata.
CAPITOLO 4. COME SI USA COSB 55
4.6.3 Prima esecuzione
L’esecuzione di COSB va lanciata da terminale: aperto un terminale bisogna
posizionarsi nella directori dov’e stato installato COSB e lanciare il comando
cosbG.rb
Capitolo 5
Casi di utilizzo
5.1 Impostazione delle verifiche
Come casi di utilizzo sono state approntate due sessioni individuali struttu-
rate in tre fasi principali. La suddivisione in fasi ha consentito di svolgere in
un unico incontro il complesso delle verifiche sul software e sul processo di
sviluppo. Ciascuna sessione e durata circa 4 ore, pertanto sono state inserite
delle pause tra una fase e l’altra.
I soggetti partecipanti alle verifiche sono stati due studenti iscritti al terzo
anno del corso di Musica elettronica presso il Conservatorio “C. Pollini” di
Padova. Entrambi gli studenti sono compositori di musica elettroacustica.
Nel dettaglio ciascuna sessione e stata suddivisa nelle fasi:
1. training dell’utente sul software;
2. utilizzo del software in autonomia da parte del compositore;
3. risposta al questionario.
La fase di training e fondamentale in quanto l’utente acquisisce le compe-
tenze che gli serviranno per a↵rontare le fasi successive. A tal fine vengono
spiegate le caratteristiche del software e la logica implementata nello stru-
mento e viene e↵ettuato un esempio di utilizzo. L’utente in questa fase puo
porre delle domande allo sviluppatore in modo da chiarire eventuali dubbi.
56
CAPITOLO 5. CASI DI UTILIZZO 57
La seconda fase prevede che l’utente utilizzi COSB in autonomia. Nelle
verifiche non sono state date direttive su come utilizzare il software ne limiti
temporali. Il soggetto ha scelto il materiale sonoro da utilizzare, ha definito
la configurazione dell’ambiente di lavoro, la posizione degli altoparlanti, la
dimensione dell’ambiente virtuale, il tempo di decadimento del riverbero e
tutte le caratteristiche necessarie a generare il codice Csound. Sempre au-
tonomamente il compositore ha scritto la partitura ed eseguito il rendering
del materiale sonoro. Dopo questa prima parte del lavoro il soggetto ha
ascoltato l’esito della spazializzazione ed e stato lasciato libero di ripetere il
procedimento appena descritto fino a che non e stato soddisfatto del risultato
ottenuto.
La terza fase consiste nella compilazione di un questionario.
1. nome e cognome
2. eta
3. anno di corso
Competenze Informatiche
4. Con che frequenza utilizzi il computer?
5. Come giudichi il tuo grado di competenza informatica?
6. Valuta le tue esperienze di programmazione in una scala da 1 a 10.
7. Conosci Ruby?
8. Conosci Csound?
9. Cosa vuol dire per te software libero, ne hai mai sentito parlare?
10. Fai parte di qualche comunita online legata alla musica? Se sı indica
quale.
Utilizzo e funzionamento di COSB
CAPITOLO 5. CASI DI UTILIZZO 58
11. Credi che COSB risponda a un’esigenza reale dei musicisti?
12. Conosci o utilizzi altri software utili a questo scopo?
13. Se la risposta alla domanda precedente e sı indica quali sono questi
strumenti.
14. Sei soddisfatto dell’esito acustico della spazializzazione ottenuta con
COSB?
15. In cosa credi si possa migliorare la resa acustica della spazializzazione?
16. Indica una funzione o un plugin che questo programma dovrebbe inte-
grare.
17. Indica una cosa che toglieresti/modificheresti.
18. Ritieni che il software risponda alle tue esigenze?
19. Dopo questa esperienza vorresti contribuire allo sviluppo del software
per renderlo piu adeguato alle esigenze tue e di altri utilizzatori?
Domande sull’esperienza proposta
20. Credi che sia utile il contatto tra il compositore e lo sviluppatore del
software?
21. Come dovrebbe avvenire questo contatto?
22. Credi che sia possibile e utile creare questo tipo di collaborazione?
23. Ti piacerebbe creare da solo i tuoi strumenti di lavoro?
24. Se la risposta alla domanda precedente e sı indica le tue motivazioni.
25. Se avessi le competenze per sviluppare i tuoi strumenti come imposte-
resti la collaborazione con gli altri sviluppatori di software?
Tecnica e creativita
CAPITOLO 5. CASI DI UTILIZZO 59
26. Da quanto tempo sei un compositore?
27. Suoni qualche strumento?
28. Utilizzi abitualmente il computer per comporre musica?
29. Qual e il rapporto tra la creativita e la tecnica nel tuo lavoro?
30. Collabori con altre persone durante il processo creativo?
Il questionario e costituito da quattro gruppi di domande. Le domande
sulle competenze informatiche servono a capire la preparazione del soggetto
e a permettere eventuali considerazioni in merito alla comunita dei composi-
tori/musicisti. Il secondo gruppo di domande serve a ottenere la valutazione
del compositore sul software e a raccogliere i suggerimenti che verranno uti-
lizzati nella fase successiva dello sviluppo. Nel successivo gruppo di domande
vengono raccolte le informazioni utili a valutare il rapporto del compositore
col l’esperienza di carattere collaborativo. L’ultimo gruppo di domande e
stato inserito allo scopo di raccogliere ulteriori informazioni sul soggetto. Il
questionario ha lo scopo di valutare come un soggetto con determinate ca-
ratteristiche e competenze si relaziona a un nuovo strumento sviluppato per
rispondere alle sue esigenze e di capire in che misura le dinamiche collabora-
tive hanno un e↵etto positivo sullo sviluppo di uno strumento dedicato alla
creazione di opere musicali.
5.1.1 Materiale audio esemplificativo
Durante il training vengono fatti alcuni esempi di scrittura della partitura
e di rendering audio per consentire al compositore di vedere il software al-
l’opera prima di utilizzarlo lui stesso. In questa fase sono stati impiegati
suoni specifici, nella fattispecie di sinusoidi e rumore bianco. Nella percezio-
ne umana le sinusoidi presentano alcuni problemi di localizzazione [1], mentre
con il rumore bianco spesso viene percepito frontale cio che proviene dalle
spalle o viceversa; la scelta e stata fatta consapevolmente per alzare il livel-
lo di attenzione del soggetto: se le prove non danno un’immagine definitiva
CAPITOLO 5. CASI DI UTILIZZO 60
delle possibilita di spazializzazione il compositore cerchera probabilmente
del materiale sonoro congruo che possa fargli comprendere in maniera piu
approfondita il funzionamento del software.
5.2 Caso d’uso numero 1
La prima sessione e stata utilizzata per verificare le scelte fatte fino a que-
sto stadio dello sviluppo e si tratta del primo contatto in assoluto con i
compositori.
L’impianto audio utilizzato per questa prima prova e a quattro canali ed e
posizionato in un’aula destinata alla didattica della musica elettroacustica. Il
setup dell’impianto e stato preparato prima dell’arrivo del compositore come
segue.
Setup quadrifonico
• 4 Casse Genelec poste agli angoli della stanza
• Mixer analogico Midas Venice
• Scheda audio Motu896
• Laptop
Il setup, molto semplice, e servito per verificare inizialmente la resa
acustica dello spazializzatore in una configurazione da studio.
La sessione comincia con il training del compositore. La dimestichezza
del soggetto consente di eseguire questa parte in poco tempo; i concetti alla
base del software sono complessi ma l’interfaccia utente fornisce un accesso
facilitato e mirato. Gia durante questa fase compaiono i primi limiti del
software e dell’implementazione eseguita.
D: Cosa vuol dire per te software libero, ne hai mai sentito parlare?
CAPITOLO 5. CASI DI UTILIZZO 61
R: Un software libero e gratuito, scaricabile da chiunque e, quindi,
utilizzabile da chiunque. Il vantaggio di questa famiglia di software e
che, solitamente, viene continuamente aggiornato e migliorato dalla
comunita che lo sviluppa, la quale e formata da chiunque lo desideri.
Tutto cio rende i software liberi potenzialmente i migliori in
circolazione.
Nelle domande successive apprendiamo che il soggetto ha avuto esperienze
nell’uso di altri software per spazializzare e che il grado di soddisfazione
nell’utilizzo di COSB e piuttosto basso. Le critiche mosse sono dirette sia
all’interfaccia che alla parte acustica e viene espressa la volonta di contribuire
allo sviluppo del software nelle fasi successive.
Nella serie di domande dalla 20 alla 25 il soggetto a↵erma di apprezzare
l’esperienza di a�ancamento allo sviluppatore del software e fornisce alcune
chiavi di lettura per valutare il lavoro svolto fino a questo punto.
Le informazioni raccolte sono state utili a ripianificare le fasi successive
dello sviluppo, integrando le osservazioni e trasformandole in task di pro-
grammazione e di progettazione dell’interfaccia secondo uno dei principi del-
l’agile development [17], ovvero rispondere al cambiamento piu che seguire un
piano prestabilito.
La critica mossa all’interfaccia grafica e che questa contenga troppe infor-
mazioni alcune delle quali non indispensabili per l’utilizzo del software. Nel-
la figura 5.1 viene evidenziata in rosso una parte dell’interfaccia considerata
superflua.
Nella fase di valutazione del questionario questa critica e stata considerata
utile e si e pertanto modificato l’interfaccia utente, spostando il form “Csound
Templates” in una finestra secondaria che il compositore puo richiamare con
un tasto. L’esito della modifica e visibile in figura 5.2
5.3 Caso d’uso numero 2
Il secondo caso d’uso e stato e↵ettuato in seguito alle modifiche al software
secondo le indicazioni del primo soggetto; sono stati inoltre corretti alcuni
CAPITOLO 5. CASI DI UTILIZZO 62
Figura 5.1: Highligt del form Csound Templates
bug scoperti nella prima sessione di prove. La struttura della sessione di
lavoro e rimasta inalterata: training, esempio d’uso, prove del compositore
in autonomia, ascolti e compilazione del questionario.
Le domande legate alle competenze informatiche mostrano una prepara-
zione simile tra il primo soggetto e il secondo, cioe una dimestichezza nell’uso
del computer e la conoscenza o almeno il contatto con le tecnologie utilizzate
per lo sviluppo. Anche in questo caso si nota la familiarita con i concetti di
free software e open source.
Le risposte al secondo gruppo di domande sull’utilizzo e funzionamento
di COSB mostrano un giudizio migliore rispetto al primo caso. Da un la-
to il giudizio e dovuto alle modifiche implementate al software, che hanno
migliorato l’esperienza soggettiva ; dall’altro, il fatto che il soggetto dichia-
ri di non avere dimestichezza con software espressamente sviluppato per la
spazializzazione e quindi l’assenza di termini di paragone influisce su aspet-
tative minori e di conseguenza sul giudizio positivo. Anche in questo caso
dal compositore arrivano suggerimenti sia sull’interfaccia grafica che sul fun-
CAPITOLO 5. CASI DI UTILIZZO 63
Figura 5.2: Il form Csound Templates spostato in una finestra separata
CAPITOLO 5. CASI DI UTILIZZO 64
Figura 5.3: Come appare l’interfaccia grafica durante il secondo test
zionamento complessivo. Il compositore promuove inoltre l’approccio delle
verifiche e dichiara di voler partecipare in maniera attiva agli sviluppi futuri.
Capitolo 6
Conclusioni
6.1 Valutazione dell’esperienza
Come sintesi del lavoro svolto, l’esperienza nel suo complesso sembra essere
stata positiva e la necessita delle premesse metodologiche confermate. La
competenza informatica dei compositori e degli studenti dei corsi di musica
elettronica si e rivelata adeguata e il metodo di sviluppo di COSB foriero
di risultati promettenti. Gli studenti si sono resi disponibili a continuare
la collaborazione a�nche il software possa rispondere sempre meglio alle
esigenze degli utilizzatori.
In particolare, e emerso il dato che il software debba contenere al suo
interno tutte le funzioni per assolvere al compito per cui e stato sviluppato
(esigenza espressa dagli studenti nel questionario).
L’esito acustico della spazializzazione e stato valutato positivamente in
fase sperimentale ma il meccanismo di rendering potra divenire un ulteriore
argomento di sviluppo.
6.2 Future work
Il processo di verifiche e sviluppo verra portato avanti per ulteriori sei mesi
con l’obbiettivo di rilasciare una versione completa dello strumento entro la
conclusione dell’anno accademico 2013/2014.
65
Bibliografia
[1] Janes Blauert, Spatial Hearing, 1974-2003.
[2] Gerald Bennett, Peter Farber, Philippe Kocher and Johannes Schutt,
The Projection of Sound in Three-Dimensional Space, 2000.
[3] John M. Chowning, Perceptual Fusion and Auditory Perspective, 1990.
[4] John M. Chowning, The simulation of moving sound sources, 1971.
[5] Heinrich Kuttru↵, Room Acoustics, 2009.
[6] R. Bianchini and A. Cipriani, Il Suono Virtuale, 2001.
[7] Barry L. Vercoe et al., The Canonical Csound Reference Manual:
Version 5.13, 2005.
[8] Andrea Valle, Kees Tazelaar and Vincenzo Lombardo, In a concrete
space. Reconstructing the spatialization of Iannis Xenakis’ Concret PH
on a multichannel setup, 2010.
[9] Durand R. Begault, 3-D Sound for Virtual Reality and Multimedia, 2000.
[10] Michele Geronazzo, Simone Spagnol e Federico Avanzini, Estimation
and modeling of pinna-related transfer functions, 2010.
[11] F. Alton Everest, Manuale di acustica, 2000
[12] John R. Pierce, La scienza del suono, 1998
66
BIBLIOGRAFIA 67
Elenco delle pagine web consultate
[13] http://www.ruby-doc.org/stdlib-2.0.0/libdoc/erb/rdoc/ERB.
html
[14] http://www.wikipedia.org
[15] http://www.fluxhome.com
[16] http://www.sibelius.com
[17] http://agilemanifesto.org
[18] http://repmus.ircam.fr/bresson/projects/spatialisation
[19] https://github.com/GameOfLife/WFSCollider-Class-Library
[20] http://www.fluxhome.com/products/plug_ins/ircam_spat
[21] http://www.csounds.com/community/about/history/
[22] https://github.com/hellska/cosb
[23] http://yaml.org/
Elenco delle figure
1.1 Dummy Head . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2 Modello sorgente - mezzo - ricettore . . . . . . . . . . . . . . . 11
1.3 Screenshot del software OMPrima . . . . . . . . . . . . . . . . 14
1.4 Screenshot del software SPAT sviluppato all’IRCAM . . . . . 14
1.5 Screenshot del software WFSCollider sviluppato da Wouter
Snoei per la fondazione Game Of Life . . . . . . . . . . . . . . 15
4.1 Interfaccia grafica come appare all’avvio . . . . . . . . . . . . 30
4.2 Files che saranno utilizzati per il rendering . . . . . . . . . . . 31
4.3 Dettaglio del form del singolo template . . . . . . . . . . . . . 31
4.4 Dettaglio del form Header Values . . . . . . . . . . . . . . . . 32
4.5 Prototipo per il generatore della partitura . . . . . . . . . . . 52
5.1 Highligt del form Csound Templates . . . . . . . . . . . . . . 62
5.2 Il form Csound Templates spostato in una finestra separata . . 63
5.3 Come appare l’interfaccia grafica durante il secondo test . . . 64
68
Progettazione, Sviluppo e Verifica del Software
COSB, Csound Orchestra Spatialize Builder
Daniele Scarano
19 Dicembre 2013
Top Related