Paolo Pastorino
3. IMPLEMENTAZIONE SU MAX MSP
3.1 L’interfaccia grafica
L’idea di semplificare i processi di esecuzione è stata concretizzata automatizzando la gestione dei potenzio- metri che controllano il segnale in ingresso, il feedback ed il segnale in uscita, inoltre è stato implementato un sistema capace di eseguire le perforazioni stabilite nell’arco temporale di ciascun periodo.
Tutte le informazioni presenti negli schemi relative alla gestione dei potenziometri sono state memorizzate come file di preset, i dati corrispondenti le perforazioni sono stati invece memorizzati all’interno di sei file .txt ovvero uno per ogni schema. All’avvio della patch viene caricata una delle sei versioni e dunque vengono richia- mati tutti i parametri suddetti.
Figura 5. Controlli interfaccia.
Le frecce in alto a sinistra (fig.5) permettono di sele- zionare la versione da eseguire, ogni qualvolta ne viene scelta una i parametri ad essa collegati vengono richia- mati cambiando così la configurazione della griglia e i ritardi per ogni “testina” di lettura.
Nel box a sinistra sono presenti i controlli per attivare l’audio in ingresso, il controllo per registrare la perfor- mance, un bottone per attivare o disattivare il microfono o i microfoni nel caso in cui si decida di utilizzarne due, ed infine un bottone che permette un reset generale della patch.
Nel box adiacente a quello appena descritto sono pre- senti i faders (potenziometri), gli indicatori delle perfo- razioni eseguite su ogni canale e dei number box grazie ai quali è possibile impostare il canale midi ed il numero del controllo nel caso in cui si decida di pilotare i faders attraverso un controller midi.
Figura 6. Estratto dello schema V dall’interfaccia
grafica.
Per facilitare le prove al performer è stato implemen- tato un sistema che permette di avviare l’esecuzione della patch da un periodo qualsiasi di qualunque ciclo, è suffi- ciente selezionare dal number box accanto alla scritta “start from period” il periodo dal quale si intende partire, dopodiché si avvia la patch cliccando il pulsante alla si- nistra della lettera relativa al ciclo scelto.
Le caselle bianche e nere della griglia presenti nell’in- terfaccia indicano gli stati dei potenziometri, quelle nere corrispondono al valore massimo - di contro - quelle bianche rappresentano il valore nullo. Il marker giallo verticale indica la lettura del periodo corrente.
La griglia in Fig.6 ha come scopo quello di dare un riferimento grafico della timeline simile a quello in par- titura.
3.2 Struttura della patch
Il motore del sistema è costituito da sei linee di ritardo per due canali (Left – Right), queste ricevono dei mes- saggi relativi ai tempi di ritardo quando la patch viene caricata e ogni qualvolta viene selezionata una versione.
Figura 7. Setup griglia schema e impostazione dei ri-
tardi.
La selezione di una versione mette in moto una serie di processi atti alla configurazione dello schema presente nell’interfaccia grafica ed al richiamo di tutti i parametri riguardanti le automazioni. Il sistema rappresentato in fig. 7 determina, a seconda della versione dello schema che viene selezionata, il numero di periodi (caselle della griglia) per ciclo (“A” nel caso in figura 7) e il relativo tempo di ritardo.
Figura 8. Griglia schema.
I valori relativi ai ritardi vengono inviati in contempo- ranea alle linee di ritardo e ai contatori che si occupano della lettura della griglia. Ogni ciclo ha un suo contatore, nel caso del ciclo A presente in fig.6 il contatore incre- menterà il suo valore di 1 ogni 22.8 secondi, tale valore, che va da 0 a n periodi, indica quale colonna della griglia deve essere letta. Ogni contatore viene avviato all’inizio del relativo ciclo. Tutti i valori prodotti dalla lettura di ciascuna riga vengono inviati alle linee di ritardo.
Figura 9. Subpatch linee di ritardo (estratto1).
Tutte le linee di ritardo ricevono il segnale in contem- poranea dal modulo receive~ L, nel caso del canale sini- stro mentre per il canale destro il modulo si chiama re-
ceive~ R, soltanto quella relativa al ciclo in funzione in-
dirizza il segnale audio verso l’output. Il segnale esce dal modulo tapout~ e viene moltiplicato per 1 sulla “testina” attiva e per 0 su quelle non attive, a valle di ogni molti- plicatore è presente un moltiplicatore unico che permette la reiterazione del segnale e quindi rende possibile l’ef- fetto feedback.
I moduli r delay determinano il ritardo in millisecondi per ciascuna linea.
Figura 10. Subpatch linee di ritardo (estratto2).
Il blocco dei moduli presente sulla destra in fig.10 agi- sce sul moltiplicatore a valle delle linee di ritardo, questo riceve i valori 1/0 relativi al feedback che vengono letti dalla griglia dello schema.
Lo stesso meccanismo di inviluppo viene applicato ai moltiplicatori che indirizzano il segnale audio verso il DAC (digital analog converter).
Figura 11. Subpatch che gestisce gli inviluppi per il
3.3 Automazione delle perforazioni
Uno degli algoritmi più complessi della patch riguarda l’automazione delle perforazioni.
Il sistema implementato legge le informazioni, rela- tive al numero di perforazioni da attuare per ogni pe- riodo, da un file .txt contenente 4 colonne (mic left, mic right, feedback left, feedback right) e 51 righe (totale pe- riodi per ogni schema), ogni schema fa riferimento ad un file diverso.
Figura 12. Estratto del file riguardante lo schema I.
La prima colonna a sinistra riporta gli indici che iden- tificano le righe, questi vanno da 1 a 51. È stato necessa- rio prima di tutto assegnare ad ogni casella dello schema un flag identificativo. Essendo variabile il numero dei pe- riodi per ciclo a seconda dello schema caricato non è stato possibile creare delle semplici costanti correlate a ciascuna casella, si è dovuto quindi procedere con delle variabili che vengono aggiornate sommando il totale dei periodi relativi al ciclo precedente a quello attivo con l’indice del primo periodo relativo al ciclo attivo. Es. se il ciclo A è costituito da 𝑛 periodi allora la variabile rela- tiva al periodo 1 del ciclo B avrà come valore 𝑛#+ 1, successivamente la variabile relativa al periodo 1 del ci- clo C avrà come valore 𝑛#+ 𝑛&+ 1 e cosi via. Il risul- tato di ciascuna somma viene indirizzato verso il modulo
coll richiamando così la riga che ha come indice lo stesso
valore. La lista restituita da coll avrà i 4 valori destinati ad un’altra parte del sistema che esegue le perforazioni.
Figura 13. Subpatch perforazioni.
La seconda parte del sistema distribuisce il numero di perforazioni previste per ogni periodo nell’arco della du- rata relativa al periodo attivo. Es. se la durata dei periodi relativi al ciclo A è di 6 secondi e per il periodo 𝑛 = 1 sono previste 4 perforazioni allora il sistema divide i 6
2 http://smc.dei.unipd.it/cim_proceedings/2008_CIM_XVII_Atti.pdf
secondi per 4; al tempo parziale viene aggiunto o sot- tratto in modo casuale un valore compreso tra −400 𝑚𝑠 e 400 𝑚𝑠, per ogni canale (mic left, mic right, feedback left, feedback right) tale intervallo cresce di 400 𝑚𝑠. Questo serve per distanziare le perforazioni tra loro.
Il sistema inoltre ricalcola il tempo residuo al seguito di ogni perforazione e procede alla reiterazione dei pro- cessi appena descritti. Per evitare che il risultato della somma di un valore casuale al tempo residuo successivo alla penultima perforazione ecceda oltre la durata del pe- riodo il risultato dell’operazione viene riscalato per evi- tare l’eccedenza.
3.4 Alterazioni timbriche
Per l’esecuzione Stockhausen ha previsto delle altera- zioni timbriche, queste sono segnalate in partitura con i simboli N, I, II, III per i cambi timbrici e con le indica- zioni Geräuschaft (più o meno rumoroso), Etwas
geräuschaft (rumoroso) e Sehr geräuschaft (molto ru-
moroso) per le gradazioni di rumore.
Tali alterazioni, come riportato nella documentazione dell’opera, possono essere realizzate sia fisicamente pre- parando lo strumento e/o mediante un sistema di elabo- razione del suono.
Nell’articolo presentato da Enrico Francioni e pubbli- cato nell’edizione del CIM XVII (2008)2 sono riportati i commenti relativi ad alcune versioni storiche eseguite da eccellenti interpreti. Le soluzioni attinenti al trattamento timbrico adottate in queste versioni sono diverse: le alte- razioni timbriche eseguite attraverso l’elettronica riguar- dano principalmente l’impiego della Ring modulation e di vocoder; per quanto riguarda invece altre alterazioni si fa riferimento all’uso di sordine nella versione per trom- bone eseguita da Barry Anderson, al cambio di strumento nella versione per flauto eseguita da Dietmar Wiesner e all’utilizzo di differenti tecniche eseguite con l’arco nella versione preparata da Enrico Francioni .
Nella patch presentata in questo articolo il problema riguardante le gradazioni di rumore viene invece affron- tato con l’utilizzo di un pitch shifter basato su linee di ritardo. Il sistema elabora il segnale su tre rami indipen- denti ognuno dei quali traspone il suono in una zona fre- quenziale differente.
La trasposizione viene controllata da un pedale di espressione la cui escursione è suddivisa in tre steps, i valori che vanno da 0.0 a 0.33 interessano la trasposi- zione di tre ottave sopra il segnale originale, lo step in- termedio che va da 0.33 a 0.66 applica una trasposizione di due ottave sotto, lo step finale traspone il segnale di 10 ottave sopra. I risultati di ogni trasposizione vengono sommati e ciascuno ha un peso differente in termini di ampiezza in modo da garantire un equilibrio tra le parti trasposte ed il segnale originale.
Per dare un risultato timbrico più interessante ho scelto di sommare al tempo di ritardo di ciascuna linea dei valori pseudocasuali compresi tra −1 𝑒 1.
Ogni step da un carattere diverso allo strumento e la variazione applicata al tempo di ritardo introduce una componente di rumore che aggiunge “rugosità” al suono dolce del vibrafono.
Per quanto riguarda invece i cambi timbrici segnalati con i simboli N, I, II, III ho deciso di affidare la scelta allo strumentista.
4. CONCLUSIONI
L’ultima revisione apportata alla patch ha permesso di raggiungere l’obiettivo posto in origine ovvero rendere più agile l’esecuzione di un’opera che presenta una certa complessità sia dal punto di vista tecnico-tecnologico che esecutivo.
La scelta di Max come ambiente di sviluppo è stata dettata da un’esigenza pratica ovvero dall’agilità che questo offre nello sviluppo e nella modifica dei lavori realizzati all’interno del suo ambiente.
Recentemente, lo studio di altri due linguaggi di pro- grammazione, abbastanza simili tra loro, come Proces- sing e p5.js3, ha orientato la mia idea verso un ulteriore sviluppo dal punto di vista grafico sia dell’opera discussa in questo articolo ma anche di altre opere le quali presen- tano un forte collegamento tra la parte grafica presente in partitura e la modalità di esecuzione. Questi due lin- guaggi sono uno standard in ambito grafico/artistico ed offrono grandi possibilità anche in campo audio grazie a librerie sviluppate da terzi come Minim4
Ritengo molto interessante, ed anche importante dal punto di vista storico, realizzare una sorta di digitalizza- zione di un’opera che interessa non solo l’aspetto sonoro ma anche quello grafico e l’interazione tra questi e l’utente.
Il lavoro resta dunque aperto a nuove evoluzioni.
3https://processing.org/
http://p5js.org/
5. BIBLIOGRAFIA
[1] K. Stockhausen: Solo für Melodieinstrument mit
Rückkopplung Nr. 19. Vienna: Universal Edition,
1969.
[2] Mark Neremberg: ‘Structure Formation’: An
Analysis of Electronic Superimpositions in Stockhausen’s Solo. 2012.
[3] Enrico Francioni: Omaggio a Stockhausen
technical set-up digitale per una performance di SOLO [Nr.19]. CIM XVII 2008.