Progettazione, Sviluppo e Verifica del Software COSB ...repo.sme-ccppd.info/did/tesi/2013_Scarano.pdf · to e alcuni modelli applicativi di riferimento. Il secondo capitolo presenta

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-


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-


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.


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


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


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


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


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


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.


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.


Figura 1.3: Screenshot del software OMPrima

Figura 1.4: Screenshot del software SPAT sviluppato all’IRCAM


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-


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-


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).


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


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.


* 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.


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.


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







;

; delays

kdeldsp1 port kdsp1/givel,0.1

; direct sound

kdelsp1w1 port ksp1w1/givel,0.1

; wall 1 reflection


; wall 2 reflection


; wall 3 reflection


; wall 4 reflection


;

; signal management

adsp1 deltapi kdeldsp1

; direct signal -> sp 1

asp1w1 deltapi kdelsp1w1

; ref w1 -> sp 1


; ref w2 -> sp 1


; ref w3 -> sp 1


; 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.


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


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


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.


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.


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.


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


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


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.


<% "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


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


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


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


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


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 %>


; 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 %>


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 %>







; 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


; wall 1 reflection


; wall 2 reflection


; wall 3 reflection


; 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 %>







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)+




(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 %>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 %>


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 %>


; 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


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


• 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.


Figura 4.5: Prototipo per il generatore della partitura


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


• 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.


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


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


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


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?


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


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-


Figura 5.2: Il form Csound Templates spostato in una finestra separata


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

Documents

Progettazione, Sviluppo e Verifica del Software COSB ...repo.sme-ccppd.info/did/tesi/2013_Scarano.pdf · to e alcuni modelli applicativi di riferimento. Il secondo capitolo presenta