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

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

9. Appendice.................................................................................................................................59

9.1. Istruzioni d’uso..................................................................................................................59

10. Ringraziamenti..........................................................................................................................63

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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

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

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

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

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

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.