ENG: italian version of my thesis, titled "generation of game soundtrack dependant on game's arousal" ITA: versione italiana della mia tesi, intitolata "generazione di colonne sonore dipendenti dall'arousal di gioco"

1. CORSO DI LAUREA TRIENNALE IN INFORMATICA
MUSICALE (F3X)
GENERAZIONE DI COLONNE SONORE DIPENDENTI
DALL’AROUSAL DI GIOCO
Relatore: Prof. Luca Andrea LUDOVICO
Correlatore: Dott. Giorgio PRESTI
Tesi di:
Walter PAPETTI
Matricola: 787518
A. A. 2013/2014

2. INDICE
1. Abstract.......................................................................................................................................4
2. Stato dell’arte..............................................................................................................................5
2.1. Definizioni di emozione......................................................................................................5
2.2. Come la musica influenza le emozioni...............................................................................7
2.3. Come il gioco influenza il mood.......................................................................................11
2.4. Elaborati inerenti...............................................................................................................13
3. Progettazione............................................................................................................................14
3.1. Mappatura dei parametri di gioco su feature musicali......................................................14
3.2. Tecnologie utilizzate (Unity 3D, Pure Data, OSC)...........................................................21
4. Implementazione......................................................................................................................23
4.1. Architettura generale.........................................................................................................23
4.2. Implementazione del lato engine.......................................................................................24
4.3. Implementazione degli script OSC....................................................................................27
4.4. Inserimento degli script all’interno dell’engine................................................................32
4.5. Implementazione del lato server audio..............................................................................36
4.5.1. Ricezione e trattamento dei dati in ingresso...........................................................39
4.5.2. Trattamento parametri in uscita per l’esecuzione musicale....................................41
5. Test...........................................................................................................................................55
6. Conclusioni e sviluppi futuri....................................................................................................56
7. Bibliografia...............................................................................................................................57
8. Sitografia..................................................................................................................................58

3. 9. Appendice.................................................................................................................................59
9.1. Istruzioni d’uso..................................................................................................................59
10. Ringraziamenti..........................................................................................................................63

4. 4
1. ABSTRACT
In questo elaborato verranno spiegate le modalità, i mezzi ed i risultati dell’implementazione di
un generatore di colonne sonore per videogiochi, capace di generare in tempo reale un
accompagnamento ritmico in funzione dell’arousal di gioco. Negli ultimi anni sono stati effettuati
diversi studi sugli effetti della musica sullo stato emotivo delle persone, sia per quanto riguarda la
valenza che l’eccitazione (arousal), e altri sulla capacità delle persone di riconoscere le intenzioni
di una particolare musica. I risultati indicano che, sebbene sia difficile evocare emozioni
specifiche ed univoche, è possibile ricreare un mood comune alla maggior parte degli ascoltatori.
Per ricreare questo mood, si sfruttano le basi comuni che quasi ogni ascoltatore utilizza per
riconoscere le intenzioni di un determinato brano: la sua velocità, la sua regolarità ritmica,
melodica e armonica, il tipo di strumenti utilizzati.
Entrando più nello specifico, ci si concentrerà maggiormente sull’influenza della parte ritmica,
con i relativi cambi di velocità, e sulla scelta di specifici campioni audio. Questi campioni
dovranno essere adatti al gioco sonificato: trattasi di una questione importante, poiché sono
presenti anche aspetti visivi ed interattivi da integrare con l’aspetto musicale. Poiché ci si è
concentrati principalmente sulla parte ritmica rispetto a quella melodica, è stato necessario poter
utilizzare un videogioco il cui gameplay potesse portare il presentare al giocatore situazioni
diverse, facilmente caratterizzabili da cambi ritmici.
L’obiettivo è poter influenzare l’esperienza di gioco attraverso l’uso della musica: sottolineando i
momenti più tensionali della partita si vuole aumentare il coinvolgimento del giocatore
incrementando il livello di sfida percepito.
Il presente documento si sviluppa in otto parti, in principio verranno spiegati alcuni concetti di
base sull’evocazione di emozioni da parte della musica e sull’influenza del mood da parte del
videogioco, quindi si passeranno in rassegna lavori inerenti al presente testo, le tecnologie
utilizzate per realizzarlo, la sua implementazione ed i possibili sviluppi futuri.

5. 5
2. STATO DELL’ARTE
Prima di addentrarsi nel campo musicale e dei modi in cui la musica possa influenzare le
emozioni, innanzitutto è necessario dare una definizione di emozione [B - 1]
, per meglio capire
cosa vuole andare a toccare questo lavoro.
Dal punto di vista scientifico vengono proposte diverse definizioni di emozione e delle sue
reazioni, da quella di Darwin legata alla teoria evolutiva a quelle nate in campo psicologico,
biologico e neurobiologico.
2.1. DEFINIZIONI DI EMOZIONE
Schachter e Singer definiscono l’emozione come un’etichetta cognitiva assegnata ad uno stato
diffuso di attivazione fisiologica, mentre “le ricerche condotte da Damasio e dal suo gruppo sono
all’origine di una teoria sull’influenza dell’emozione sui processi decisionali. Secondo il
neurologo, che nega la dicotomia emozione-ragione, la ragione è guidata dalla valutazione
emotiva delle conseguenze dell’azione e la separazione tra mente e corpo è insensata e
irrealistica: la mente è un prodotto evolutivo, finalizzato al soddisfacimento delle nostre necessità
fisiche e psichiche, e per raggiungere questo obiettivo deve disporre di informazioni derivanti da
quelle strutture nervose che elaborano le risposte affettivo-emotive emerse dalle esperienze e dai
contenuti della memoria” [S - 1]
.
Darwin individuò un insieme di tipi di comunicazione non verbale che viene utilizzato per
esprimere una “risposta coordinata ad un evento emotigeno che coinvolge più sistemi di
risposta”. Questo insieme contiene: le espressioni facciali, le vocalizzazioni, le posture, i gesti e
le risposte autonomiche. In questo elaborato verrà descritto il meccanismo di risposta alle
emozioni nella sua totalità e non le singole reazioni.
Per quanto riguarda invece la definizione dell’emozione in sé, si può affermare che “in termini
evolutivi, o darwiniani, la loro principale funzione consiste nel rendere più efficace la reazione
dell'individuo a situazioni in cui si rende necessaria una risposta immediata ai fini della
sopravvivenza, reazione che non utilizzi cioè processi cognitivi ed elaborazione cosciente. Le
emozioni rivestono anche una funzione relazionale (comunicazione agli altri delle proprie

6. 6
reazioni psicofisiologiche) e una funzione auto-regolativa (comprensione delle proprie
modificazioni psicofisiologiche). Si differenziano quindi dai sentimenti e dagli stati d'animo” [S -
2]
.
“In psicologia con il termine sentimento (derivato dal latino sentire, percepire con i sensi) si
intende uno stato d'animo ovvero una condizione cognitivo-affettiva che dura più a lungo
delle emozioni […]”. “Per sentimento genericamente si indica ogni forma di affetto: sia quella
soggettiva, cioè riguardante l'interiorità della propria individuale affettività, sia quella rivolta al
mondo esterno. Quando il termine viene usato nel significato di “senso (sentimento) di sé
esprime la coscienza della propria esistenza come complesso dei moti cognitivi e corporei” [S - 3]
.
Un’altra importante teoria è quella stesa dallo psicologo americano Paul Ekman, che presenta
cinque assunzioni principali:
o Alcune espressioni facciali sono dei markers universali ed affidabili di stati emotivi
attivati
o Espressioni facciali discrete corrispondono ad emozioni soggettive (discrete)
o Le espressioni facciali discrete fanno parte di un insieme emotivo di risposte
o Le espressioni facciali discrete sono considerate affidabili in culture diverse
o Le espressioni facciali discrete svolgono una funzione di comunicazione interpersonale e
di regolazione sociale
Dall’esecuzione di diversi test è successivamente giunto alla creazione del FACS (Facial Action
Coding System), un sistema di codifica delle espressioni facciali, eseguito suddividendo il viso in
distinti gruppi muscolari, poiché si è scoperto che per esprimere una certa emozione si utilizzano
i medesimi muscoli facciali in tutte le culture.
La reazione visibile ad un determinato evento emotigeno è un’azione eseguita volontariamente
dopo aver filtrato la reazione interiore; questo può avere diverse cause, delle quali le principali
sono la cultura ed il contesto, che possono portare a dissimulare o simulare determinate emozioni
con un’intensità variabile.

7. 7
Figura 2. I MECCANISMO PER LA PERCEZIONE DI UN’EMOZIONE
Allo stato attuale, a livello psicologico si confrontano due ipotesi:
o Una introduce il concetto di appraisal, ossia la percezione inconscia di un certo stimolo
che causa un certo cambiamento nel sistema nervoso autonomo per generare l’emozione
o L’altra invece introduce il concetto di arousal, ossia l’attivazione indistinta del sistema
nervoso autonomo unita ad appraisal cognitivo, suddiviso in primario (inconscio) e
secondario (conscio)
Il sistema nervoso autonomo viene suddiviso in due parti con funzioni opposte: il sistema
simpatico e quello parasimpatico; il primo è il principale responsabile dei meccanismi di
attivazione dell’organismo mentre il secondo lo pone in uno stato di quiete.
2.2. COME LA MUSICA INFLUENZA LE EMOZIONI
In questa sezione verranno introdotti i meccanismi di elaborazione della musica da parte del
fruitore e di come questa possa generare emozioni [B - 2]
. Ci si baserà soprattutto su uno studio
interamente dedicato a questo argomento, sottolineandone gli aspetti essenziali.
A conclusione di una serie di test sono stati delineati sei meccanismi atti all’evocazione delle
emozioni da parte della musica:
o Riflesso del tronco encefalico
o Condizionamento valutativo
o Contaminazione emozionale
o Immaginazione visiva
o Memoria episodica
o Aspettativa musicale

8. 8
Scorrendo la lista dei nomi dei vari meccanismi, si intuisce che ognuno possiede un grado diverso
di indipendenza dal mondo esterno, come, per esempio, l’impatto culturale sulla valutazione della
musica; la seguente tabella ne esemplifica il peso per ogni meccanismo.
MECCANISMO IMPATTO CULTURALE
Riflesso del tronco encefalico Basso
Condizionamento valutativo Alto
Contaminazione emozionale Basso
Immaginazione visiva Alto
Memoria episodica Alto
Aspettativa musicale Alto
Tabella 2. I LIVELLO DI IMPATTO CULTURALE SULLO SVILUPPO DEI PARAMETRI COGNITIVI PER L’ELABORAZIONE
DELLE EMOZIONI TRAMITE LA MUSICA [B - 2]
Dalla precedente tabella si capisce che esistono vari modi in cui si può influenzare, se non
addirittura corrompere, la valutazione emotiva di un determinato brano: all’impatto culturale si
può aggiungere la situazione sociale od il peso dato al ricordo di certi eventi.
Ogni meccanismo viene attivato da regioni differenti del cervello in istanti diversi: per esempio,
la reazione del tronco encefalico è istantanea ed inconscia, mentre l’aspettativa musicale viene
elaborata più in ritardo, nella corteccia.

9. 9
MECCANISMO TIPO DI
INFLUENZA
VELOCITA’
DELL’INFLUENZA
LIVELLO DI
INFLUENZA
VOLONTARIA
LIVELLO DI
COSCIENZA
MODULARITA’ DIPENDENZA
DALLA
STRUTTURA
MUSICALE
Riflesso del tronco
encefalico
Stimolazione
generica
Alta Basso Basso Alta Media
Condizionamento
valutativo
Emozioni di base Alta Basso Basso Alta Bassa
Contaminazione
emozionale
Emozioni di base Alta Basso Basso Alta Media
Immaginazione
visiva
Tutte le emozioni Bassa Alto Alto Bassa Media
Memoria episodica Tutte le
emozioni,
soprattutto la
nostalgia
Bassa Medio Alto Bassa Bassa
Aspettativa musicale Sorpresa, stupore,
piacere, “brividi”,
disappunto,
speranza, ansia
Media Alto Medio Media Alta
Tabella 2. II LIVELLO DI INFLUENZA DI EVENTI INTERNI O ESTERNI SUI VARI MECCANISMI COGNITIVI PER L’ELABORAZIONE EMOZIONALE DELLA MUSICA [B - 2]

10. 10
La tabella 2.II mostra con che intensità ogni meccanismo possa essere influenzato da fattori
esteriori od interiori all’ascoltatore, dipendenti od indipendenti dalla struttura musicale.
A livello del tronco encefalico viene semplicemente ricevuto un impulso generico, che verrà poi
elaborato ed etichettato tramite i meccanismi attivati successivamente ed idealmente posizionato
nel piano valenza/arousal in figura 2.II; innanzitutto il lavoro proposto vuole tentare di creare
stimoli a livello del tronco, puntando in seguito alla modulazione valutativa dell’aspettativa
musicale, tramite cambi ritmici rapidi, provocando stupore e sorpresa.
A questi meccanismi si associano due assi in cui vengono poste le emozioni al fine di
classificarle, ossia la valenza e l’arousal: il primo indica la qualità od il tipo di emozione, mentre
il secondo ne connota l’intensità.
Figura 2. II DISPOSIZIONE DELLE EMOZIONI SUL PIANO VALENZA/AROUSAL [B - 3]
Dal punto di vista musicale è possibile influenzare l’elaborazione e la conseguente classificazione
sui suddetti assi attraverso la modulazione di determinati parametri musicali.

11. 11
PARAMETRO MUSICALE ASSE INFLUENZATO
VELOCITA’ AROUSAL
REGOLARITA’ VALENZA
TIMBRO VALENZA+AROUSAL
CONSONANZA VALENZA
INTENSITA’ AROUSAL
Tabella 2. III RELAZIONE TRA I PARAMETRI MUSICALI E GLI ASSI DI ELABORAZIONE MUSICALE
Bisogna altresì sottolineare che l’influenza a livello di un asse non esclude quella dell’altro.
In questo elaborato ci si è concentrati sull’influenza dell’asse dell’arousal, senza però ignorare
del tutto la valenza.
2.3. COME IL GIOCO INFLUENZA IL MOOD
In questa sezione verranno brevemente spiegati i meccanismi attraverso i quali i parametri di
gioco possono influenzare il mood (umore) del giocatore nell’affrontare la partita [B - 4]
.
Innanzitutto si possono distinguere tre aspetti: immersione (immersion), impegno (engagement) e
presenza (presence), ma tutti sfruttabili allo stesso modo per ottenere il medesimo risultato, ossia
il coinvolgimento del giocatore. Si parla di immersione quando si deve spiegare il lato più
soggettivo della questione, e di impegno quando si tratta il lato più tecnico, come l’abilità e la
confidenza col gameplay, mentre la presenza può essere inserita nel mezzo.
Verranno ora presi singolarmente in considerazione i tre aspetti presentati sopra.
È possibile ottenere una totale immersione anche senza dover raggiungere il fotorealismo, poiché
qui entra in gioco la soggettività del giocatore, che potrebbe prediligere, per esempio, un certo
stile grafico rispetto ad un altro. Questo è possibile perché l’immersione in questo campo viene
definita come la sensazione di trovarsi da qualche altra parte, isolandosi dalla realtà. Una buona
storia può garantire un alto livello d’immersione in essa, sia essa letta, ascoltata o guardata.

12. 12
Inoltre, ci sono studi che rivelano che il cervello elabora le parole lette come se fossero
immagini [B - 5]
, perciò potrebbe bastare davvero poco per ottenere un buon livello d’immersione.
Per quanto riguarda il lato puramente tecnico, ovviamente una maggiore difficoltà porta ad un
maggiore impegno per di superare gli ostacoli che si pongono davanti. Ma come si ottiene una
maggiore difficoltà? Dipende dal genere di gioco, ma di base, dove possibile, si tenta di
aumentare il numero di avversari, la loro intelligenza artificiale e di rendere accattivante il level
design. Da ciò si capisce che un maggior numero di nemici, accompagnato ad una maggiore
difficoltà nell’affrontarne anche solamente uno, può aumentare il senso di sfida.
Oltre al gameplay puro, anche il game design ed il punto di vista del giocatore può influenzare il
livello di immersione: per il primo si può parlare del grande aumento dell’utilizzo della grafica
3D rispetto a quella 2D o isometrica, possibile grazie ad un enorme salto tecnologico negli ultimi
vent’anni; invece per il secondo, sta aumentando sempre di più il numero di giochi sviluppati in
prima persona, o al massimo in terza.
Nell’implementazione di questo progetto, non si è potuto purtroppo utilizzare un gioco sviluppato
ad hoc, ma si è dovuto scegliere su un gioco preesistente, abbassando le possibilità di ottenere un
buon livello d’immersione, tuttavia quello di sfida viene incrementato, per merito dell’influenza
sull’asse dell’arousal che ha la patch creata.
Per quanto concerne la presenza, invece, questa viene descritta come l’insieme delle percezioni
che si ha del mondo reale; per questo motivo, l’uso di un’esperienza sensoriale mediata con un
mondo fittizio, come accade nel caso dei videogiochi, viene definita telepresenza (telepresence).
Quando si utilizza un mezzo per vivere una storia, si ha una doppia esperienza, quella del mondo
reale e quella del mondo narrato, perciò si tenta in tutti i modi di isolarsi dal mondo reale per
vivere al massimo l’esperienza virtuale, utilizzando delle cuffie per esempio. Un metodo per
ottenere un buon livello di presenza (e in parte anche di immersione) è di creare un mondo
virtuale coerente con se stesso.
Concludendo, si può creare un collegamento tra i due assi principali che descrivono
l’elaborazione delle emozioni nella musica con quelli relativi all’immersione ed all’impegno, in
cui l’asse dell’arousal può essere collegato all’impegno e quello della valenza all’immersione,
mentre la presenza può influenzare sia l’arousal che la valenza, poiché un più elevato senso di

13. 13
presenza all’interno del gioco, può sia aumentare la confidenza con le meccaniche, influenzando
sia il livello d’impegno che quello immersivo.
Figura 2. III INFLUENZA TRA I PARAMETRI EMOZIONALI DI GIOCO CON QUELLI EMOZIONALI
2.4.ELABORATI INERENTI
In questa sezione verranno passati in rassegna tutti gli studi e le applicazioni inerenti al presente
elaborato che è stato possibile reperire.
Allo stato attuale non è ancora possibile fornire una dettagliata bibliografia dei lavori che trattano
della sonificazione in tempo reale di videogiochi, soprattutto perché in questo campo agiscono
soprattutto appassionati dell’argomento, con conseguente dispersione di nozioni. In ogni caso è
possibile citare due video dimostrativi: uno mostra una semplice sonificazione di un videogioco
tramite l’utilizzo di Unity 3D e Pure Data [S - 4]
, mentre l’altro si concentra sull’invio di dati di
gioco da Unity 3D a Pure Data tramite OSC [S - 5]
.

14. 14
3. PROGETTAZIONE
3.1. MAPPATURA DEI PARAMETRI DI GIOCO SU FEATURE
MUSICALI
In questa sezione si entrerà maggiormente nei dettagli del progetto proposto, cominciando a
descrivere e spiegare le scelte implementative, ossia le modalità ed i criteri con cui si legano i
parametri di gioco a quelli musicali.
Prima di cominciare, è doveroso un excursus sulla scelta del videogioco, che deve essere adatto al
tipo di lavoro proposto, ossia deve essere parametrizzabile in maniera adeguata. Parlando in
termini di genere videoludico, i giochi a piattaforme (platform) non sono molto adatti, poiché
buona parte di essi non utilizza il meccanismo delle statistiche né sul protagonista né sui vari
nemici o alleati; sono invece preferibili giochi che sfruttano questo meccanismo, come i giochi di
ruolo, gli action o gli arcade. Nello specifico è stato scelto “Space Invaders”, un gioco arcade a
livelli, molto semplice nelle meccaniche, ma che offre buoni spunti implementativi.
Studiando il codice di gioco, è stato possibile estrapolare i seguenti parametri: numero di vite del
personaggio; stato degli scudi difensivi; numero, velocità ed altezza dei nemici.

15. 15
Figura 3. I SCHERMATA DI GIOCO DI “SPACE INVADERS”
Dal lato musicale, invece, si è riusciti a collegare i suddetti parametri con i seguenti aspetti
musicali: velocità, intensità, timbro e regolarità.

16. 16
Figura 3. II TABELLA DELLE FUNZIONI UTILIZZATE, CON I RELATIVI DATI D’INGRESSO ED I PARAMETRI
INFLUENZATI DAI CORRISPETTIVI VALORI IN USCITA
Sono state effettuate delle precise scelte progettuali prima di implementare le funzioni mostrate
dalla precedente tabella, dove fn indica le diverse funzioni:
o I parametri legati, direttamente o indirettamente, allo status del giocatore (numero di vite
e stato degli scudi) vengono collegati a quei parametri audio che, opportunamente
modificati, possono generare tensione, come la regolarità della musica ed il volume della
stessa
o I parametri legati ai nemici vengono invece collegati a ciò che può rendere più o meno
aggressivo un brano, ossia la sua velocità ed il timbro degli strumenti utilizzati
Concludendo, le funzioni sopra elencate hanno gli scopi e l’implementazione seguenti:
o La funzione f1 collega il numero di vite all’intensità del brano serve a creare maggiore
tensione tramite l’intensità della musica, nel caso in cui il giocatore stia esaurendo le vite
a disposizione; collega il numero di vite al moltiplicatore dell’intensità è stata
implementata a soglie, ossia,

17. 17
Figura 3. III RAPPRESENTAZIONE DELLA FUNZIONE F1
o La funzione f2 collega il numero delle vite e lo stato degli scudi alla regolarità del brano
serve a creare un senso di destabilizzazione nel caso in cui la partita sia in una fase critica
del suo svolgimento; è stata implementata dando un peso ad entrambi i valori in ingresso,
secondo la funzione
in cui il valore iniziale della funzione è
con 18 numero approssimato del numero di colpi che ogni scudo può subire e 4 numero
degli scudi; ad ogni colpo subito

18. 18
Figura 3. IV RAPPRESENTAZIONE DELLA FUNZIONE F2
o Le funzioni f3 e f4 collegano i vari parametri dei nemici alla velocità del brano ed al
timbro degli strumenti utilizzati per la sua esecuzione ripropongono nella musica
l’aumento di aggressività dei nemici presenti sullo schermo; la prima è stata implementata
in modo differenziale: ad ogni aumento del valore in ingresso, ossia della velocità dei
nemici, il beat per minute (BPM) aumenta di un valore pari a 20, con un valore iniziale di
80, si ottiene così un semplice rapporto lineare tra la velocità dei nemici e la velocità della
colonna sonora

19. 19
Figura 3. V RAPPRESENTAZIONE DELLA FUNZIONE F3
mentre la seconda necessita di una più lunga spiegazione: innanzitutto bisogna introdurre
parzialmente la parte implementativa del lavoro qui descritto, a causa dell’influenza pesante
che ha questa funzione all’interno dell’economia del brano. Le parti ritmiche sono divise in
gruppi d’esecuzione separate ed indipendenti, all’interno delle quali si utilizzano campioni
audio e pattern diversi: la modifica del valore della funzione qui descritta serve a selezionare
il gruppo da suonare, ed a modificare l’indice di modulazione del sintetizzatore FM, creato in
parallelo alla drum machine. La funzione in questione è basata su un primo calcolo di un
indice di “tensione”, che viene utilizzato per selezionare i gruppi e gli indici di modulazione
al cui valore viene poi applicato un controllo per definire il gruppo d’esecuzione ed il valore
dell’indice di modulazione

20. 20
Figura 3. VI RAPPRESENTAZIONE DELLA FUNZIONE F4 PER IL GRUPPO D’ESECUZIONE

21. 21
Figura 3. VII RAPPRESENTAZIONE DELLA FUNZIONE F4 PER L’INDICE DI MODULAZIONE
Da come si può evincere dalle soglie poste dalle ultime due condizioni, il sintetizzatore FM verrà
attivato solamente con il raggiungimento del terzo gruppo, ma, una volta entrato in funzione,
continuerà a suonare anche in caso di cambio di gruppo.
3.2. TECNOLOGIE UTILIZZATE
In questa sezione verranno illustrate le tecnologie utilizzate ed i rispettivi vantaggi.
Innanzitutto, per poter implementare il progetto proposto, è necessario avere a disposizione i
seguenti tipi di software:
o Per quanto riguarda il gioco, un motore grafico per la gestione, la modifica ed il testing
o Per quanto riguarda invece il comparto sonoro, un software per la sintesi, la risintesi e la
gestione di file audio esterni

22. 22
Per il primo è stato scelto Unity 3D, poiché è il motore grafico con la curva d’apprendimento più
breve, oltre che il più utilizzato nel campo videoludico per la sua gratuità. Per il secondo è stato
scelto Pure Data, un software che sfrutta il paradigma della programmazione grafica, anziché il
codice testuale, il che lo rende di più facile apprendimento, oltre a facilitare l’implementazione di
patch che sfruttano la sua capacità di creare audio in maniera procedurale.
Un discorso a parte merita invece il metodo tramite il quale collegare i due software sopra
presentati: non si necessita di un programma apposito, ma di librerie o script create ad hoc, come
libpd, una libreria che permette l’incapsulamento delle funzioni di Pure Data in Unity 3D, oppure
di script appositi per la trasmissione di messaggi OSC (Open Sound Control). Si è optato per la
seconda soluzione, oltre che per la maggior semplicità d’implementazione, anche per le
potenzialità che possiede: infatti la comunicazione tramite messaggi OSC avviene tramite
connessione Internet client-server, nella quale l’engine esegue il compito di client, poiché
richiede un servizio (ossia richiede lo stream audio per sonificare la propria applicazione),
inviando i dati necessari per il suo ottenimento, mentre Pure Data esegue il compito del server
audio, poiché riceve le richieste, accompagnate dai dati di gioco, ed invia l’audio parametrizzato.
L’unico punto debole di questa scelta è la necessità di mantenere aperti i due software utilizzati,
poiché sia client che server devono rimanere attivi durante tutta la durata della comunicazione.
“OSC è un protocollo per la comunicazione tra computer, sintetizzatori ed altri strumenti
multimediali, ottimizzato per le moderne tecnologie di rete” [S - 6]
. Permette la trasmissione di una
grande varietà di dati, incapsulati in pacchetti OSC, e la scelta del protocollo di trasporto più
adatto: TCP o UDP [B - 6]
. In questo caso, poiché la comunicazione avviene in locale sullo stesso
computer, è preferibile utilizzare UDP per la sua maggior leggerezza, perché, nonostante TCP sia
più affidabile, non c’è rischio di perdita di dati in una comunicazione di questo tipo. La
leggerezza del protocollo UDP è data dal fatto che non effettua i controlli avanzati sull’eventuale
corruzione o perdita dei dati che invece effettua TCP, perché predilige la velocità di trasmissione
alla correttezza dei dati trasmessi.

23. 23
4. IMPLEMENTAZIONE
In questo capitolo verranno spiegate le scelte progettuali ed implementative legate al lato più
tecnico del lavoro, cominciando da una spiegazione del funzionamento dell’architettura generale,
per poi entrare più nel dettaglio, mostrando il funzionamento di ogni suo componente.
Prima di cominciare a discutere dell’architettura, conviene premettere che, da ora in poi nel corso
del testo, ci si riferirà a “Unity 3D” come engine o motore grafico.
4.1. ARCHITETTURA GENERALE
Da ciò che è stato spiegato nella sezione dedicata alle tecnologie utilizzate, è logico aspettarsi che
i due programmi funzionino separatamente in contemporanea e che si passino i dati dei rispettivi
calcoli tramite il canale fornito da OSC. In particolare, è l’engine che passa i dati di gioco a Pure
Data, che effettua dei calcoli, basati sulle funzioni precedentemente presentate. Lo schema
appena descritto è rappresentabile in questo modo.

24. 24
Figura 4. I SCHEMA A BLOCCHI DEL LAVORO PROPOSTO
4.2. IMPLEMENTAZIONE DEL LATO ENGINE
In questa sezione verranno affrontate le questioni legate al ruolo del motore grafico nell’ambito
progettuale.
L’engine ha il compito di fornire i dati, calcolati all’interno del proprio codice di gioco, necessari
per l’attivazione ed il funzionamento della patch di Pure Data.
Per rendere ciò possibile, innanzitutto bisogna individuare all’interno del codice le variabili che
tengono traccia dei dati richiesti: queste devono essere pubbliche, per poter essere visibili anche
da parti di codice esterne a quella in cui è stata dichiarata, o comunque vanno in qualche modo
esportate nello scope delle classi relative ad OSC. Unity 3D supporta diversi linguaggi di
programmazione, quali Javascript, C# ed altri, utilizzati anche nello stesso progetto, sebbene
questo aggiunga la complessità di dover gestire all'interno di un singolo progetto diversi

25. 25
linguaggi, dall'altro lato offre anche caratteristiche interessanti, ad esempio: le variabili pubbliche
possono essere utilizzate anche da script che utilizzano un linguaggio diverso da quello della sua
dichiarazione: nel nostro caso, il gioco scelto per l’esperimento è stato sviluppato
prevalentemente in Javascript, mentre lo script per lo scambio di messaggi OSC è in C#.
Come detto, innanzitutto è preferibile che le variabili che si desidera passare a Pure Data siano
pubbliche, come mostrato di seguito.
Figura 4. II DICHIARAZIONE DI VARIABILE PER L’INVIO DI DATI TRAMITE TRAMITE SENDMESSAGE()
Successivamente, Unity 3D mette a disposizione la seguente funzione (dichiarazione per
javascript):
SendMessage (“methodName”, var);
che permette di invocare il metodo di cui si necessita, passandogli la variabile richiesta; a
prescindere dal linguaggio in cui il metodo è scritto, questo serve per aumentare ulteriormente
l’interoperabilità tra i linguaggi presenti.
Il metodo richiamato deve essere dichiarato all’interno di una classe pubblica (per poter essere a
sua volta visto dall’esterno) in questo modo (per C#):
public class ClassName : MonoBehaviour {
void methodName (type var) {
}
}
“MonoBehaviour è la classe base da cui deriva ogni script” [S - 7]
e deve essere necessariamente
dichiarata nel caso in cui si programmi in C# o Boo, mentre in Javascript ogni script deriva
automaticamente da essa.

26. 26
Una volta dichiarate ed inizializzate le variabili necessarie, è possibile interfacciare il codice di
gioco con quello che gestisce lo scambio di messaggi OSC, semplicemente richiamando la
funzione SendMessage () in qualsiasi punto del codice. Le figure sottostanti ne mostrano un
esempio pratico sul codice utilizzato.
Figura 4. III SEZIONE DI CODICE DI GIOCO CON INVIO DATI AD OSCPLAYERSENDER.CS
In questo modo è possibile inviare dati da qualsiasi punto del codice: per esempio, ad ogni
modifica della variabile in questione. Nel caso sopra mostrato, la variabile, InvaderCount, viene
dichiarata pubblica (è implicito in Javascript) ed il suo valore viene inviato dopo averle assegnato
il valore di default all’interno della funzione d’inizializzazione StartInvaders ().
Prima di passare al funzionamento dell’elemento all’altro capo della comunicazione, ossia Pure
Data, verrà prima spiegato il funzionamento della componente di raccordo tra i due, ossia gli
script che permettono lo scambio di messaggi OSC tra le due entità.

27. 27
4.3. IMPLEMENTAZIONE DEGLI SCRIPT OSC
In questa sezione si affronterà la questione del collegamento tra l’engine e Pure Data, con
particolare attenzione al codice utilizzato, tentando di risultare il più esplicativi possibile per
facilitare l’eventuale ripresa di questo lavoro da parte di terzi, poiché la rete scarseggia di
contenuti completi ed esaustivi su questo argomento.
Innanzitutto bisogna precisare che questo codice è frutto di studi da parte di appassionati, quindi
potrebbe non risultare professionale o performante al massimo, poiché nell’open source è
consuetudine applicare il concetto di “meglio avere del cattivo codice piuttosto che non averne”.
In ogni caso, meritano una menzione coloro che hanno modificato il codice, che ha comunque
necessitato di ulteriori modifiche per risultare adeguato allo scopo prefissato da questo testo: Carl
Emil Carlsen, che ha creato il cuore di questo script, e Jóhannes Gunnar Þorsteinsson, che ha
inserito aggiunte personali per far meglio interagire il codice con Unity 3D e Pure Data.
Gli script utilizzati per garantire l’interoperabilità tra Unity 3D e Pure Data, tramite lo scambio di
messaggi OSC, sono tre:
o OSCplayerSender.cs, questo script serve essenzialmente come raccoglitore delle varie
funzioni che vengono invocate dal codice di gioco; è il primo anello della catena che
riceve i dati dall’engine
o OSCsender.cs, riceve i dati da OSCplayerSender, effettua un primo filtraggio dei dati da
inviare, implementato tramite semplici condizioni applicate alle variabili in ingresso,
invoca l’impacchettamento dei dati in messaggi OSC e li invia
o OSC.cs, è il cuore operativo che permette la comunicazione tra i due software; riceve i
messaggi da OSCsender e li impacchetta in messaggi TCP o UDP, inviandoli a
destinazione

28. 28
Figura 4. IV SCRIPT OSCPLAYERSENDER.CS
Analizzando il codice dello script OSCplayerSender.cs, si può notare la presenza della funzione
oscSendEnemies (), che è la funzione che viene richiamata sotto forma di stringa nella figura
4.III, che raffigura la sezione di codice relativa alla funzione SendMessage (); oscSendEnemies ()
riceve in ingresso una variabile di tipo integer chiamata invaderCount, come la variabile passata
dal codice di gioco. Allo stesso modo, tutte le altre funzioni presenti nello script
OSCplayerSender.cs vengono invocate all’interno del codice di gioco e ricevono delle variabili
dello stesso tipo e con lo stesso nome di quelle inviate dal codice di gioco.

29. 29
All’interno di ogni funzione ne viene richiamata un’altra, collegata all’oggetto pubblico
oscSender di tipo OSCsender, a cui si passa la variabile appena ricevuta.
Figura 4. V INIZIALIZZAZIONE DELLO SCRIPT OSCSENDER.CS
Nella sezione dedicata alla dichiarazione delle variabili del codice appena riportato si può notare
che viene creata la classe denominata OSCsender e che al suo interno viene creata una variabile
pubblica oscPlayerSender di tipo OSCplayerSender, che è la classe creata all’interno dello script
OSCplayerSender.cs: in questo modo i due script possono “vedersi” a vicenda, passandosi le
variabili di cui si necessita.
Le altre variabili, ad eccezione di Osc osc, hanno il ruolo di variabili di stato, al fine di mantenere
l’ultimo valore della variabile da controllare.
Nella funzione d’inizializzazione Start () vengono inizializzate tre variabili: una stringa per
memorizzare l’indirizzo IP di destinazione, e due numeri interi per memorizzare le due porte di
comunicazione; il tutto viene assegnato all’oggetto osc di tipo OSC, che, come si vedrà in

30. 30
seguito, è la classe dichiarata nello script OSC.cs. Infine, nella funzione OnApplicationQuit (),
viene rilevata l’eventuale chiusura dell’engine, al fine di disattivare gli script, tramite la funzione
Stop ().
Figura 4. VI UNA DELLE FUNZIONI PER IL PASSAGGIO DATI AD OSC.CS DA OSCSENDER.CS
Nell’immagine 4.VI si può vedere il codice di una delle funzioni presenti nello script: è la
funzione che viene richiamata da oscSendEnemies (), la quale le passa la variabile invaderCount.
All’interno della riga di creazione del nuovo messaggio OSC si può notare la presenza di
un’etichetta “/enemies” associata alla variabile invaderCount: questa servirà in seguito per
l’instradamento del messaggio all’interno di Pure Data. Ciò è dovuto al fatto che ogni messaggio
inviato tramite Open Sound Control necessita di un’etichetta distintiva, in caso si volesse
distinguere i messaggi gli uni dagli altri al lato del ricevente.
Al termine di questa catena di passaggi di variabili e richiami di funzioni si trova OSC.cs, che,
come detto, è il vero fautore dell’impacchettamento dei messaggi e del loro invio.
Figura 4. VII FUNZIONE SEND() IN OSC.CS

31. 31
Non c’è stato bisogno di modificare il suo codice, poiché tutte le volte che si intende inviare un
messaggio, è sufficiente invocare la sua funzione Send (), inclusa nella classe principale OSC,
che è pubblica, quindi visibile anche al suo esterno, infatti viene creata una variabile osc, di tipo
OSC, all’interno dello script OSCsender.cs: in questa maniera è possibile richiamare le funzioni
create nella classe OSC all’interno dell’altro script.
Figura 4. VIII FUNZIONE STOP() IN OSC.CS
Allo stesso modo, quando l’applicazione che invia i messaggi viene chiusa, viene richiamata una
la funzione Stop (), creata in OSC.cs, così viene interrotto l’invio dei messaggi.
Prima di passare all’implementazione dell’altro capo della comunicazione, ossia Pure Data, è
necessario spiegare brevemente come vengono effettivamente inseriti gli script all’interno di
Unity 3D.

32. 32
GAME CODE OSCPlayerSender.cs OSCsender.cs OSC.cs
var data : type; public class
OSCplayerSender :
MonoBehaviour{
public OSCsender
oscSender;
}
public class
OSCsender :
MonoBehaviour {
public
OSCplayerSender
oscPlayerSender;
OSC osc;
}
public class OSC
public class
OSCMessage
SendMessage
(“OSCmethodName”,
data);
void OSCmethodName
(type data) {
oscSender.methodName
(data);
}
Public void
methodName (type
data) {
OSCmessage = new
message
(“/etichetta”,
data);
osc.Send
(message);
}
public void Send
(OSCMessage
message) {
}
Tabella 2. IV TABELLA RIASSUNTIVA DELLE DICHIARAZIONI E DELLE CHIAMATE DI FUNZIONE NEGLI SCRIPT OSC
PER IL PASSAGGIO DEI DATI
4.4. INSERIMENTO DEGLI SCRIPT ALL’INTERNO DELL’ENGINE
In questa breve sezione si spiegherà brevemente i passaggi necessari per poter inserire
correttamente gli script all’interno del motore di gioco.
Innanzitutto, questi vanno inseriti all’interno della cartella in cui si trova il codice di gioco e, più
precisamente, devono seguire questo percorso (considerando la cartella che contiene il gioco

33. 33
come la directory radice): “GameDirectory” -> “Assets” -> “Scripts” -> “SceneN”, con
quest’ultima che è la scena da cui si riceve i dati di gioco, quindi solitamente si tratta delle scene
di gioco e non di quelle di presentazione.
Figura 4. IX GERARCHIA DELLE DIRECTORY
Prima di proseguire, è necessaria una spiegazione: in Unity si può suddividere il gioco in scene,
che fungono da contenitori, a cui vengono solitamente assegnati ruoli diversi, per poter gestire
separatamente le varie parti del gioco, ossia le varie schermate di presentazione ed i vari livelli di
gioco; nel caso di studio ci sono tre scene: la schermata di presentazione (Title), quella di gioco

34. 34
(Game) e quella di gestione degli input (General); quella da cui si deve ricevere i dati necessari è
quella di gioco.
Figura 4. X CREAZIONE ED INSERIMENTO IN OSCSENDER
Successivamente, bisogna collegare gli script OSC con gli oggetti di gioco in cui sono stati
inseriti gli script che gestiscono i dati di cui si necessita. Innanzitutto bisogna creare un’entità
vuota (“create empty”) dall’opzione “create” all’interno della sezione dedicata alle gerarchie
(“hierarchy”) e rinominarla OSCsender. Successivamente bisogna selezionarla ed aggiungerci
uno script tramite il tasto “Add Component”, scegliere “script” e selezionare OSCsender.cs. A
quel punto si creerà una variabile Osc Player Sender, a cui si dovrà collegare l’entità che contiene
gli script necessari, cliccando il tasto sulla destra di quella riga e selezionando “Main Camera”.

35. 35
Figura 4. XI INSERIMENTO ALL’INTERNO DI MAIN CAMERA
Per concludere la procedura, bisogna selezionare “Main Camera” dalla sezione “hierarchy” ed
aggiungere lo script OSCplayerSender.cs, seguendo il medesimo procedimento, aggiungendo
OSCsender alla variabile Osc Sender che si verrà a creare una volta aggiunto lo script.
A questo punto, Unity 3D è collegato e pronto per inviare messaggi OSC.

36. 36
4.5. IMPLEMENTAZIONE DEL LATO SERVER AUDIO
Prima di procedere, spiegando la struttura del lato dedicato a Pure Data, il più corposo, bisogna
prima descriverne il funzionamento: Pure Data agisce tramite patch, singole finestre in cui viene
scritto codice, tramite programmazione grafica; queste patch possono essere collegate tra loro in
diversi modi:
o Subpatching, ossia creando delle patch all’interno di altre, che sono richiamabili solo
all’interno della patch creatrice
o Abstractions, le astrazioni sono delle subpatch indipendenti; sono patch a sé stanti, che
possono essere richiamate da qualsiasi patch o subpatch; quando si modifica
un’abstraction, viene modificata ogni istanza che è stata richiamata da qualsiasi patch
o Graph on parent, è un raffinamento dei due metodi precedenti, che permette la
visualizzazione di alcuni elementi della subpatch o dell’astrazione, scelti dall’utente
Tutte gli oggetti, i messaggi e le funzioni qui presentate sono tratti dai manuali cartacei di Pure
Data [B - 7] [B - 8]
e consultabili sul manuale online [S - 8]
.
Nel lavoro qui proposto, le patch e sottopatch presenti sono le seguenti:
o oscdata, è la patch che riceve i pacchetti osc e li incanala
o DataToSoundrack&dac, è la patch che effettua il calcolo dei parametri audio in base ai
parametri di gioco ricevuti e contiene il DAC
o DrumMachine, è la patch che gestisce l’esecuzione musicale della parte ritmica in base ai
parametri ricevuti e l’emissione dell’audio
o exemetro, questa patch calcola la velocità del metronomo d’esecuzione
o player, è la patch che effettua l’effettiva esecuzione delle slice audio
o noteloss, è la patch che effettua il calcolo del possibile drop delle note che riceve in
ingresso
o MarkovAnalysis, è la patch che effettua il calcolo della matrice di Markov di primo
ordine, in base al brano che riceve

37. 37
o FMsynth, riceve i dati relativi all’altezza delle note da suonare, attivando un semplice
sintetizzatore a modulazione di frequenza
Dal punto di vista progettuale, il lavoro sul lato di Pure Data è rappresentabile come in figura.
Figura 4. XII SCHEMA LOGICO DI FUNZIONAMENTO DEL LATO SERVER AUDIO
Invece, entrando maggiormente nel dettaglio del lavoro proposto, quest’ultimo è rappresentabile
in questa maniera.

38. 38
Figura 4. XIII GRAFICO DEL FUNZIONAMENTO DELLE PATCH DEL LATO SERVER AUDIO
Nell’immagine soprastante sono presenti solo le patch (le sottopatch verranno introdotte volta per
volta, quando si presenteranno).
Come si può vedere, ci sono due tipi di frecce che collegano le varie entità: quelle più spesse
indicano un’invocazione con eventuale restituzione di valori, invece quelle tratteggiate un
passaggio indiretto dei dati senza invocazione tramite gli oggetti send e receive.
La presentazione delle suddette patch verrà divisa in due macro blocchi logici di funzionamento,
che nel caso di studio sono: ricezione e trattamento dati in ingresso e trattamento parametri in
uscita per l’esecuzione musicale.

39. 39
4.5.1. RICEZIONE E TRATTAMENTO DEI DATI IN INGRESSO
oscdata
Figura 4. XIV PATCH OSCDATA
Come detto in precedenza, questa patch riceve ed instrada i messaggi OSC ricevuti dall’engine.
Entrando maggiormente nel dettaglio, le funzioni richiamate dagli oggetti udpreceive,
unpackOSC e routeOSC sono funzioni incluse nella libreria esterna mrpeach, che viene importata
tramite l’oggetto import. Udpreceive apre una connessione in entrata sulla porta 8500 e riceve
eventuali messaggi in ingresso, sfruttando il protocollo UDP. Una volta ricevuti i messaggi,
questi vengono spacchettati dall’oggetto unpackOSC per poter essere letti e successivamente
passati all’oggetto routeOSC, che li instrada a seconda dell’etichetta che accompagna ogni
messaggio; le etichette qui usate devono corrispondere a quelle applicate all’interno degli script
OSC.
Per concludere, tutti i dati ricevuti ed instradati vengono infine passati alla patch
DataToSoundtrack&dac.

40. 40
DataToSoundtrack&dac
Figura 4. XV PATCH DATATOSOUNDTRACK&DAC
La presente patch, denominata DataToSoundtrack&dac, ha la funzione di ricevere i dati
instradati da oscdata e di utilizzarli per calcolare i parametri audio.
Come si può notare dallo screenshot, la patch ha sei inlet, o ingressi, che, come si può notare dai
commenti vicini ed elencati da sinistra verso destra ricevono i seguenti dati:
accensione/spegnimento della patch addetta all’esecuzione musicale, numero di vite, stato degli
scudi, velocità, numero ed altezza dei nemici. Il primo viene immediatamente passato alla patch
DrumMachine, il secondo viene utilizzato per calcolare l’eventuale aumento di volume e la
percentuale di drop delle note insieme al terzo, mentre il terzo serve per calcolare il bpm e,
insieme agli ultimi due, il gruppo d’esecuzione per la parte ritmica e l’indice di modulazione per
la parte melodica.
Successivamente, i tutti i dati ottenuti, a parte l’indice di modulazione, vengono passati alla patch
DrumMachine, mentre quello rimasto viene passato alla patch FMsynth, che è controllata dalla
patch denominata MarkovAnalysis, la cui accensione od il cui spegnimento è deciso dal numero
di gruppo precedentemente calcolato: da ciò si evince che il sintetizzatore avrà un ruolo

41. 41
abbastanza marginale nell’economia della musica, poiché si attiverà solo al raggiungimento del
terzo ed ultimo gruppo.
Entrando maggiormente nel dettaglio delle funzioni, si è deciso di utilizzare un metodo ad
intervalli per la scelta del valore d’uscita: il valore ottenuto passa attraverso degli if separati in
cui, se il valore rientra nell’intervallo d’analisi, si ottiene il valore desiderato in uscita, altrimenti
si ottiene il valore -1; in base a questo valore poi si attivano/disattivano delle porte, la cui
espressione di controllo è > -1: se l’espressione risulta essere vera, il valore ottenuto passa,
altrimenti no. Questo controllo, che esclude tutti i valori negativi, è possibile a causa del fatto che
tutte le funzioni restituiranno valori positivi.
Per concludere, tutto lo streaming audio restituito dalle patch qui invocate viene passato al dac
(Digital to Analog Converter), applicando un semplice effetto di panning:
o Solo i suoni profondi sono centrati
o I suoni a frequenza media, come quello del rullante, ed il risultato dell’esecuzione della
mano sinistra, sono indirizzati solo sul canale sinistro
o I suoni più acuti, come quelli dei piatti, ed il risultato dell’esecuzione della mano destra
sono passati al solo canale destro
4.5.2. TRATTAMENTO DEI PARAMETRI IN USCITA PER
L’ESECUZIONE MUSICALE
MarkovAnalysis
Prima di spiegare nel dettaglio il funzionamento di questa patch, conviene effettuare una piccola
introduzione ai processi markoviani [B - 9]
.
“Un processo stocastico markoviano o processo di Markov è un processo stocastico nel quale
la probabilità di transizione che determina il passaggio ad uno stato di sistema dipende
unicamente dallo stato di sistema immediatamente precedente (proprietà di Markov) e non
dal come si è giunti a tale stato (in quest'ultima ipotesi si parla di processo non markoviano)” [S -
9]
.

42. 42
Dall’analisi effettuata tramite processo di Markov si ottiene una matrice di transizione, come
quella rappresentata qui in figura.
Figura 4. XVI ESEMPIO DI MATRICE DI MARKOV [S - 10]
In cui k è il numero di passi effettuati dall’analisi per ottenere la suddetta matrice, N è la sua
cardinalità ed n è l’istante attuale.
Questa matrice contiene delle probabilità di scatto, quindi dei valori che si attestano
nell’intervallo [0, 1]. “Inoltre, pensando al significato di ogni elemento e al fatto che una catena
di Markov deve trovarsi sempre in uno tra gli stati ammissibili, risulta evidente che la somma,
fatta sugli stati di arrivo, delle probabilità di transizione da uno stato i, in un qualsiasi numero k di
passi, debba essere unitaria” [S - 10]
.
Figura 4. XVII PROPRIETA’ DELLE MATRICI DI MARKOV [S - 10]
È possibile applicare questo metodo analitico ai file midi, i quali sono formattati in maniera
standard e forniscono tutte le informazioni relative alle note presenti nel brano tramite gli
omonimi messaggi. In questo caso verrà creata una matrice di transizione che coinvolge le altezze
delle varie note suonate.
Dal punto di vista implementativo, è consigliabile utilizzare file di dimensioni relativamente
ridotte, poiché la velocità dell’analisi dipende dalla lunghezza e dalla velocità del brano scelto.
Inoltre, nel caso il brano contenesse più tracce, queste verrebbero unite insieme, compromettendo
il valore dell’analisi; per questo motivo è preferibile utilizzare brani contenenti un solo
strumento.
Dopo questa breve ma necessaria introduzione teorica, è possibile mostrare il funzionamento
della patch MarkovAnalysis.

43. 43
Figura 4. XVIII PATCH MARKOVANALYSIS
Come si può notare dall’immagine, vengono effettuate due analisi in parallelo: questo è dovuto al
fatto che si è scelto di dividere l’esecuzione per le due mani di una singola esecuzione di
pianoforte.
Il brano scelto è “Fatal Tragedy” dei Dream Theater, il cui file midi è stato ottenuto dalla
conversione di un file in formato .gp5 [S - 11]
.
In ingresso ci sono due oggetti, un inlet che immette un bang per l’attivazione dell’esecuzione ed
un oggetto receive, che riceve un bang dal metro di controllo, per temporizzarne l’esecuzione.
Per non giungere impreparati al momento dell’esecuzione del brano, la sua analisi viene
effettuata al momento stesso dell’apertura della patch tramite l’oggetto loadbang, che invia un

44. 44
automaticamente un segnale al momento dell’apertura della patch in cui è inserito, o di quella che
richiama la suddetta patch, come è nel nostro caso.
L’oggetto seq riceve in ingresso un file midi tramite il messaggio read, che gli passa il file da
leggere. A questo punto, seq registra tutti gli eventi che rileva, per poi passarli all’analizzatore
alla ricezione del messaggio bang, passando per l’oggetto midiparse, che suddivide i messaggi
midi in ingresso a seconda del loro tipo; il primo outlet restituisce pitch e velocity della nota
entrante e, poiché si necessita solo del primo, questi vengono divisi tramite l’oggetto unpack,
passando il valore dell’altezza all’oggetto anal, che conta il numero di passaggi tra un dato stato e
gli altri, e prob, che ne estrapola la matrice di transizione. A questo punto, tramite l’invio di un
bang all’oggetto prob, verrà scelto uno stato da restituire, basandosi sulla matrice appena
ottenuta, il cui valore di pitch viene convertito ad uno di frequenza per poter essere letto dal
sintetizzatore FM.
FMsynth
Prima di entrare nel dettaglio implementativo, anche qui è necessaria una piccola introduzione
teorica alla sintesi ed in particolare a quella a modulazione di frequenza.
La sintesi dei suoni è la loro generazione, in questo caso artificiale, seguendo modelli diversi:
o Sintesi additiva
o Sintesi sottrattiva
o Sintesi a modulazione d’ampiezza (AM)
o Sintesi a modulazione ad anello (RM)
o Sintesi a modulazione di frequenza (FM)
Tra tutte queste tecniche si è scelto quest’ultima per la complessità dei suoni che fornisce, legata
alla relativa semplicità implementativa.
y (n) = A * sin(2πnfc/R + I * sin2πnfm/R)
Quello sopra mostrato è il modello matematico della modulazione di frequenza, in cui A è
l’ampiezza di picco del segnale, n l’indice del campione in questione, fc e fm sono le frequenze
rispettivamente della portante e della modulante ed I è l’indice di modulazione. L’indice di

45. 45
modulazione controlla la presenza di componenti frequenziali all’interno dello spettro sonoro;
quindi, più il valore dell’indice di modulazione è elevato e più ricco di frequenze risulta il suono
in uscita.
“Per ottenere la modulazione FM è sufficiente disporre di due generatori sinusoidali controllabili
in ampiezza e frequenza e combinabili opportunamente tra loro proprio secondo uno schema di
modulazione di frequenza” [B - 10]
.
Figura 4. XIX RAFFIGURAZIONE DI UNA SEMPLICE MODULAZIONE DI FREQUENZA, CON PORTANTE ED UNA
MODULANTE [B - 11]
Nel caso di studio è stato applicato un semplice modello di sintesi FM, con la fondamentale ed
una sola modulante.

46. 46
Figura 4. XX PATCH SYNTHFM
Nella presente figura è rappresentata l’implementazione della sintesi a modulazione di frequenza
per il lavoro proposto. Così come avviene per l’analisi, anche per la sintesi sono stati creati due
moduli in parallelo: in quello di sinistra il modulo per la sintesi dell’esecuzione della parte della
mano sinistra ed in quello di destra quella della parte della mano destra.
Questa patch riceve in input, da sinistra verso destra: l’altezza della nota da generare per il primo
modulo, il segnale di avvio/spegnimento della patch, l’indice di modulazione, uguale per
entrambi i moduli, e l’altezza della nota da generare per il secondo modulo. Inoltre è presente un
oggetto receive per la ricezione del valore in millisecondi del metronomo di controllo, che viene
utilizzato per parametrizzare i due metronomi d’esecuzione della patch, moltiplicandolo per un
numero pseudo-casuale tra 1 e 3, che indica il numero di note da suonare in un quarto, all’interno
della patch exemetro. Successivamente i metronomi attivano le rispettive sottopatch dropL e
dropR, le quali pescano un numero decimale pseudo-casuale nell’intervallo [0, 1], controllandone
poi il valore tramite l’oggetto moses, il cui valore d’inizializzazione indica la soglia, al di sotto
della quale si attiva l’outlet di sinistra, altrimenti quello di destra: in questo modo si implementa
la probabilità di drop delle note.

47. 47
Figura 4. XXI SOTTOPATCH DROPL Figura 4. XXII SOTTOPATCH DROPR
Figura 4. XXIII PATCH EXEMETRO
A questo punto, dopo aver scelto quali note far suonare ai due moduli, si giunge al momento
della loro effettiva esecuzione: i valori giunti vengono ora attivati dai metronomi, che attivano il
modello per la modulazione di frequenza. Il valore dell’altezza viene inserito al posto della
portante e viene moltiplicato per 0.4 per ottenere il valore della frequenza della modulante.
Da notare il fatto che la frequenza della modulante sia tale da essere udibile, poiché altrimenti si
otterrebbe solamente un effetto di vibrato della portante.

48. 48
Figura 4. XXIV PATCH CARRIER ENVELOPE
I valori ricalcolati del metronomo vengono invece inviati alla patch CarrierEnvelope, la quale
calcola i vari intervalli temporali dell’inviluppo applicato alla frequenza portante ed a quella della
modulante, rappresentate nell’immagine seguente.
Figura 4. XXV GRAFICO DEGLI INVILUPPI UTILIZZATI PER IL SINTETIZZATORE FM

49. 49
L’inviluppo della portante è suddiviso in: attacco, decay iniziale, sustain e decay. I primi due
insieme hanno una durata pari ad 1/5 del valore in ingresso, così come il decay, mentre il sustain
occupa i 3/5 del tempo della nota; l’inviluppo della modulante è invece più semplice, poiché è
formato da una retta che va da zero a uno nel tempo indicato.
Questa patch riceve in ingresso il valore attuale in millisecondi del metronomo e viene attivata ad
ogni esecuzione dallo stesso.
Infine, i dati numerici ottenuti vengono utilizzati per creare l’audio tramite gli oggetti osc~ e
mandati in uscita tramite degli outlet e rappresentati su due array distinti tramite l’oggetto
tabwrite~, attivato dal metronomo d’esecuzione.
DrumMachine
Questa patch ha il compito gestire tutta l’esecuzione della parte ritmica, inviandola in
conclusione al dac, presente nella patch DataToSoundtrack&dac.
Figura 4. XXVI PATCH DRUMMACHINE
Come si può notare dall’immagine soprastante, questa patch può essere definita come il cuore di
tutta la parte musicale creata su Pure Data: è formata da diverse sottopatch, riceve tutti i dati

50. 50
elaborati da DataToSoundtrack&dac ed invia alla patch SynthFM la velocità attuale del
metronomo espressa in millisecondi tramite l’oggetto send ms ed il beat del singolo quarto.
Prima di descrivere il metodo seguito per ottenere un’esecuzione pseudocasuale, è necessario
spiegare come è stato realizzato il database di campioni sonori, dopo ovviamente averli scelti.
Per alleggerire il carico di lavoro da continui caricamenti di singoli campioni, si è scelto di
“metterli in fila” in maniera equidistante, in modo tale da permettere la suddivisione in parti
uguali del file ottenuto; questo viene caricato solamente all’avvio della patch all’interno della
sottopatch slicer, alla quale si fornisce il percorso del file desiderato ed il numero di parti in cui
suddividerlo tramite il file di testo file4slicer.txt. Dopo aver suddiviso il suddetto file audio, la
sottopatch fornisce il valore della durata di ogni frammento sia in numero di campioni che in
millisecondi: questo servirà in seguito, al momento dell’esecuzione. Infine, tramite l’oggetto
soundfiler viene salvato il file caricato all’interno dell’array denominato drumfile.

51. 51
Figura 4. XXVII SOTTOPATCH SLICER
Al momento della ricezione del comando di accensione, viene attivato il DSP tramite il
messaggio ;pd dsp $1, in cui la variabile indica il valore in ingresso (1 per l’accensione e 0 per lo
spegnimento). A questo punto viene attivato il metronomo di controllo, inizializzato ad un valore
di 1000 millisecondi, che riceve in ingresso il valore da applicare dalla patch DataToSoundtrack;
questi manda un bang a frequenza regolare ad un contatore, che ripete perpetuamente il conto da
1 a 4, che altro non sono se non i quarti, il cui valore viene inviato alle sottopatch snare, kick e
charlie, le quali hanno il compito di controllare la probabilità d’esecuzione della nota in
questione, leggendo dai rispettivi file snare.txt, kick.txt e charlie.txt la riga corrispondente,
determinata dal quarto, un offset pseudocasuale, ottenuto tramite l’oggetto random, calcolato ad
ogni inizio di battuta per ottenere il pattern da suonare, ed un altro dipendente dal gruppo

52. 52
d’esecuzione in cui ci si trova.; bisogna infatti specificare che l’esecuzione è stata suddivisa in tre
momenti di gioco distinti: calma, allerta ed attenzione, tutti e tre dipendenti dalla situazione di
gioco, fornita dai suoi parametri. L’invio del numero di gruppo viene controllato tramite un
contatore del numero di battute ed avviene ogni due battute: questo controllo è necessario per
dare un senso di linearità musicale alla soundtrack.
Figura 4. XXVIII SOTTOPATCH KICK
Tornando al controllo d’esecuzione ed entrandovi maggiormente nello specifico, questo viene
effettuato tramite la patch noteloss, che riceve dal file di testo un valore compreso tra 0 e 1 e lo

53. 53
confronta con un valore pseudocasuale estratto in un intervallo con il massimo variabile,
dipendente dai calcoli effettuati nella patch DataToSoundtrack&dac.
Figura 4. XXIX PATCH NOTELOSS
A questo punto, le note che hanno superato la suddetta barriera, possono essere suonate.
L’esecuzione avviene tramite altre tre sottopatch: exesnare, exekick ed execharlie, le quali
ricevono il beat dal metro di esecuzione, ottenuto tramite la patch exemetro (vedi figura ), il
numero di note ed il numero di quarto da suonare, scelgono la riga con l’indice corrispondente a
quest’ultimo nei propri file exesnare.txt, exekick.txt ed execharlie.txt ed inviano i dati relativi al
numero di fetta da riprodurre e quattro, che è il numero massimo di note eseguibili per ogni
quarto, valori di accento; questo permette l’esecuzione di quarti, ottavi, terzine e sedicesimi.

54. 54
Figura 4. XXX SOTTOPATCH EXEKICK
A questo punto i dati vengono passati alla patch player, che riceve sia i dati relativi alla
dimensione della fetta da slicer, sia il numero di fetta e la sua accentuazione dalle sottopatch
d’esecuzione, che il valore di amplificazione calcolato da DataToSoundtrack&dac.

55. 55
Figura 4. XXXI PATCH PLAYER
Questa, tramite l’oggetto vline~, legge dalla tabella drumfile dal punto indicato dal numero di
fetta da suonare, utilizzato come indice di lettura e crea uno stream audio, rimandato alla patch
genitore.
Per concludere, tutti gli stream audio vengono inviati al dac, o convertitore digitale-analogico,
presente nella patch DataToSoundtrack&dac.
5. TEST
A causa della relativa scarsità di situazioni di gioco e, di conseguenza, dell’eccessiva linearità
della parte artistica implementata, piuttosto che dei test rigorosi si è preferito far effettuare delle
prove a puro scopo conoscitivo ad un campione piuttosto ristretto di utenti, a cui è stato
successivamente richiesto un parere non vincolante sulla qualità generale del lavoro svolto,
tramite una breve sessione di gameplay. Il tester, munito di cuffie, ha dovuto tentare di superare
un livello del gioco proposto, fornendo poi un proprio parere sulla soundtrack ascoltata.

56. 56
Le indicazioni fornite sono state, seppur poche, tendenzialmente positive: il cambio di gruppo è
stato ben percepito, così come il cambio di timbro degli strumenti.
6. CONCLUSIONI E SVILUPPI FUTURI
In conclusione, si può definire il lavoro proposto come una potenziale base di partenza per
chiunque volesse implementare un simile sistema di soundtrack in tempo reale, da cui è possibile
trarre alcune buone idee e stratagemmi implementativi, come l’utilizzo di una comunicazione via
Internet per lo scambio di dati tra le due applicazioni, utile per alcuni generi di giochi, come, per
esempio, i MMORPG, ossia i Massive Multiplayer Online Role Play Games.
Da quello che si è potuto notare nel corso di questo elaborato, questo lavoro è un contenitore di
diversi applicativi, tutti teoricamente indipendenti l’uno dall’altro; per questo motivo
potenzialmente sono molti i tipi di applicazione che può avere un lavoro come questo: per
esempio, è possibile creare giochi in cui l’utente possa creare un proprio mondo personalizzato,
in cui ospitare altri giocatori per le fasi di gioco online, all’interno delle quali anche i rumori
d’ambiente e la musica dipendano dal tipo di mondo di gioco, per poter diffonderli agli altri
partecipanti, creando ogni volta un’atmosfera unica; oppure si potrebbe sviluppare solo parte del
lavoro proposto per migliorare l’implementazione dei cosiddetti serious games, ossia giochi il cui
scopo principale non è il divertimento, bensì la riabilitazione. Un’altra possibilità è l’acquisire
idee e materiali a piene mani da questo lavoro, tentando di migliorarne, per esempio, il livello
esecutivo, con l’introduzione di metriche diverse dal 4/4, o di strumenti diversi, oppure con
l’incremento dell’importanza della valenza nell’economia musicale, con melodie ed armonie
complesse; dal punto di vista implementativo si potrebbe invece sviluppare un più agile controllo
per il drop delle note, oppure rendere più elastico il lato esecutivo della drum machine,
permettendo un’esecuzione più colorita della parte ritmica, oppure ampliare il proprio set di
suoni, inserendo più blocchi di campioni da caricare per ogni situazione di gioco.

57. 57
7. BIBLIOGRAFIA
[B - 1] Corso di computazione affettiva e comportamentale, prof. Giuseppe Boccignone, 2014
[B - 2] “Emotional responses to music: the need to consider underlying mechanism”, Patrick N.
Juslin, Daniel Västfjäll, 2008
[B - 3] “The role of nonlinear dynamics in affective valence and arousal recognition”, dott. E. P.
Scilingo, 2012
[B - 4] “A method for analyzing 3-D videogames”, capitolo 3 - “Immersion, engagement and
presence”, Alison McMahan, 2003
[B - 5] “Adding words to the brain’s visual dictionary: novel word learning selectively sharpens
orthographic representation in the VWFA”, The journal of neuroscience, Laurie S. Glezer, Judy
Kim, Josh Rule, Xiong Jiang, Maximilian RiesenHuber, 2015
[B - 6] “Reti di calcolatori e Internet – Un approccio top-down”, ed. Pearson, quarta edizione,
James F. Kurose, Keith W. Ross, 2011
[B - 7] “Inventare il suono con Pure Data – Manuale introduttivo di musica elettronica”, versione
0.4.3, Francesco Bianchi, 2013
[B - 8] “Pure Data”, Luka Princic, Adam Hyde, Derek Holzer, Daniel Shiffman, William
Abernathy, Caio Barrios, Hans-Christoph Steiner, Jonathan Wilkes, Alexandre Porres, Thomas
Goose, Joao Pais, Ben Baker-Smith, Corey Fogel, Felipe Ribeiro, Heiko Recktenwald, Georg,
Martin Shied, Paul Sobczak, Neil Hickey, Laura Garcia-Barrio, Marius Schebella, Evan Raskob,
Servando Barreiro, Olsen Wolf, Vincent Rioux, Antonio Roberts, Max Neupert, David A.
Arraya, Koray Tahiroglu, Roman Haefeli, Lukas Kaser, Penko Sound, Daniel Prieto, Maarten
Brinkerink, Steve Bull, Evelina Domnitch, Patrick Davison, Lachlan Wimset, Frank Barknecht,
Lucas Kendo, Alvaro Ortiz, Alejo Duque, Phil Tesner, Tad Bisaha, Michela Pelusio, Scott
Fitzgerald, Anique Vered, Julio Terra, Mark Hadman, Simone Marin, Pall Thayer, First Last,
2012
[B - 9] “Calcolo delle probabilità ed elementi di statistica”, edizione Utet, Luciano Daboni, pp.
238 – 284

58. 58
[B - 10] “Informatica applicata al suono – Digital audio – Teoria e pratica”, edizione Maggioli,
seconda edizione, prof. Mario Natalino Malcangi, 2008
[B - 11] Informatica applicata alla musica, prof. Goffredo Haus
8. SITOGRAFIA
[S - 1] http://www.treccani.it/enciclopedia/neurologia-delle-emozioni_%28XXI-Secolo%29/,
visitato il 10/04/2015
[S - 2] http://it.wikipedia.org/wiki/Emozione, visitato il 10/04/2015
[S - 3] http://it.wikipedia.org/wiki/Sentimento, visitato il 10/04/2015
[S - 4] https://vimeo.com/57614598, visitato il 10/04/2015
[S - 5] https://www.youtube.com/watch?v=HgX6-JSDADE, visitato il 10/04/2015
[S - 6] http://opensoundcontrol.org/introduction-osc, visitato il 10/04/2015
[S - 7] http://docs.unity3d.com/ScriptReference/MonoBehaviour.html, visitato il 10/04/2015
[S - 8] http://en.flossmanuals.net/pure-data, visitato il 10/04/2015
[S - 9] http://it.wikipedia.org/wiki/Processo_markoviano, visitato il 10/04/2015
[S - 10] http://it.wikipedia.org/wiki/Matrice_delle_probabilit%C3%A0_di_transizione, visitato il
10/04/2015
[S - 11] http://tabs.ultimate-guitar.com/d/dream_theater/fatal_tragedy_ver2_guitar_pro.htm,
visitato il 10/04/2015

59. 59
9. APPENDICE
9.1. ISTRUZIONI D’USO
All’interno del file readme.txt, qui riportato, vengono spiegati i concetti principali, nel caso si
volesse modificare i parametri esecutivi della parte ritmica.
Questi sono i campioni audio presenti nel file "file4slicer.wav" col
rispettivo numero di slice:
0, "ambient 1"
1, "ambient 2"
2, "ambient 3"
3, "ambient 4"
4, "ambient 5"
5, "heavy crash"
6, "kick dry 1"
7, "kick dry 2"
8, "kick wet"
9, "light bell"
10, "light crash 1"
11, "light crash 2"
12, "light crash 3"
13, "low tom dry"
14, "low tom wet"
15, "mid crash"
16, "noise FX"
17, "snare dry 1"
18, "snare dry 2"
19, "snare wet"
20, "stick wet 1"
21, "stick wet 2"
22, "stick wet 3"
23, "stopped charlie"
24, "synth FX"
25, "TAIKO 1"

60. 60
26, "TAIKO 2"
27, "TAIKO 3"
28, "TAIKO 4"
I file "kick.txt", "snare.txt" e "charlie.txt" sono stati scritti con il
seguente formato:
INDICE, #NOTE %DROP;
il cui scopo principale consiste nel determinare a monte in quali quarti
suonare o meno le note indicate, mentre i file "exekick.txt", "exesnare.txt"
ed "execharlie.txt" rispettano il seguente:
INDICE, #SLICE %VOLUME1 %VOLUME2 %VOLUME3 %VOLUME4;
ed hanno il compito di indicare quale campione utilizzare e la loro
accentuazione (le note accompagnate da valore nullo non vengono eseguite)
Il file "file4slicer.txt" comunica a Pure Data il percorso del file da
utilizzare accompagnato dal numero di slice da applicarvi
A seguire viene presentato un dei file di controllo, nello specifico kick.txt:
1, 1 0.8;
2, 0 0;
3, 0 0;
4, 0 0;
5, 1 0.8;
6, 0 0;
7, 0 0;
8, 0 0;
9, 1 0.8;
10, 0 0;
11, 0 0;
12, 0 0;
13, 1 0.8;
14, 0 0;
15, 0 0;
16, 0 0;
17, 1 0.9;
18, 0 0;
19, 0 0;
20, 0 0;
21, 3 0.9;
22, 0 0;
23, 0 0;
24, 0 0;
25, 2 0.9;
26, 0 0;
27, 0 0;
28, 0 0;
29, 2 0.9;
30, 0 0;

61. 61
31, 2 0.9;
32, 0 0;
33, 1 1;
34, 0 0;
35, 2 1;
36, 0 0;
37, 2 1;
38, 0 0;
39, 1 1;
40, 0 0;
41, 1 1;
42, 1 1;
43, 1 1;
44, 1 1;
45, 0 0;
46, 3 1;
47, 0 0;
48, 3 1;
Invece quello sottostante è uno dei file d’esecuzione, nello specifico exekick.txt:
1, 25 0.8 0 0 0;
2, 0 0 0 0 0;
3, 0 0 0 0 0;
4, 0 0 0 0 0;
5, 26 0.8 0 0 0;
6, 0 0 0 0 0;
7, 0 0 0 0 0;
8, 0 0 0 0 0;
9, 27 0.8 0 0 0;
10, 0 0 0 0 0;
11, 0 0 0 0 0;
12, 0 0 0 0 0;
13, 28 0 0.8 0 0;
14, 0 0 0 0 0;
15, 0 0 0 0 0;
16, 0 0 0 0 0;
17, 8 0.9 0 0 0;
18, 0 0 0 0 0;
19, 0 0 0 0 0;
20, 0 0 0 0 0;
21, 8 0.9 0.7 0 0;
22, 0 0 0 0 0;
23, 0 0 0 0 0;
24, 0 0 0 0 0;
25, 8 0 0.9 0 0;
26, 0 0 0 0 0;
27, 0 0 0 0 0;
28, 0 0 0 0 0;
29, 0 0.9 0.7 0 0;
30, 0 0 0 0 0;
31, 0 0.7 0.5 0 0;
32, 0 0 0 0 0;
33, 6 1 0 0 0;
34, 0 0 0 0 0;
35, 6 0.9 0.7 0 0;
36, 0 0 0 0 0;
37, 7 1 0.8 0 0;
38, 0 0 0 0 0;
39, 7 0.7 0 0 0;
40, 0 0 0 0 0;
41, 6 1 0 0 0;
42, 6 0.7 0 0 0;
43, 6 0.8 0 0 0;
44, 6 0.7 0 0 0;

62. 62
45, 0 0 0 0 0;
46, 7 1 0.8 0.8 0;
47, 0 0 0 0 0;
48, 7 0.8 0.6 0.6 0;

63. 63
10. RINGRAZIAMENTI
Vorrei concludere ringraziando tutti coloro che mi hanno sostenuto, come i miei genitori, coloro
che mi hanno aiutato, come il mio relatore ed il mio correlatore, e coloro che hanno vissuto con
me questo periodo della mia vita, come i miei colleghi di università ed i miei amici.