MusicXII

Manuale Tecnico

v. 1.0

Il protocollo MusicXII è volutamente di una semplicità estrema. Penso, infatti, che i musicisti debbano occuparsi di musica, non di informatica: l'elaboratore deve essere sempre un mezzo, mai un fine. Nella voce di menu "MusicXII" ho accennato al ruolo fondamentale del file denominato "flusso": si tratta di un normalissimo file di testo elaborato con TextEdit (Mac) o WordPad (Win) contenente le istruzioni da compilare in sequenza. Il file viene letto e interpretato esclusivamente dopo il segno "@" seguito da return: tutto ciò che precede la "chiocciola" viene ignorato dal compilatore (è possibile quindi inserire note e quant'altro nella stessa pagina di flusso, evitando, naturalmente, l'uso del carattere "@", unico marker identificativo).

Esaminiamo il contenuto di un file di flusso (per chiarezza espositiva ho numerato le righe, il codice operativo non necessita di numerazione):

1 // MusicXII - © 2008 deBers
2
3 @
4 mxii:miditest
5 mthd:1,240
6 copy:0,Copyright 2008 deBers
7 nomeseq:0,Brano Test
8
9 n:1,Cn0,1/4,mf
10 n:2,En0,3/8,30

La prima riga è una annotazione: le note possono essere inserite anche all'interno del flusso (ovvero dopo il simbolo "@") se fatte precedere da una o due barre diagonali. Le annotazioni vengono ignorate dal compilatore. Nella posizione in cui si trova poteva quindi essere scritta senza doppia barra. Segue uno spazio (riga 2); la riga 3 contiene il marker identificativo di inizio flusso (la chiocciola, "@").

La riga 4 è obbligatoria: contiene il marker "mxii" seguito da due punti e il titolo del brano. Il file viene identificato come "flusso" esclusivamente dal marker "mxii". Dalla riga 5 alla 7 abbiamo una serie di metaeventi (vedi il manuale): nel nostro esempio, il valore della semiminima (riga 5), una indicazione di copyright (riga 6) e il nome della sequenza come apparirà all'interno del midi file. Segue uno spazio (riga 8).

Le linee 9 e 10 contengono due istruzioni da compilare, in questo caso due note determinate ad esecuzione immediata, identificate dalla lettera "n" seguita da due punti e dai parametri di riferimento (canale, nome della nota, durata, intensità). I quattro parametri sono più che sufficienti, in un midi file, all'esatta descrizione dell'evento da eseguire. In questo caso, le note vengono eseguite contemporaneamente perchè disposte su canali diversi: se avessimo assegnato lo stesso canale ad entrambe avremmo avuto in successione il do naturale in ottava 0 (Cn0 - durata: 1/4) e il mi naturale in ottava 0 (En0 - durata 3/8).

Nella sezione "Manuale" sono descritte le sintassi con esempi dei codici attualmente attivi.

Il file di flusso deve essere salvato, necessariamente, con estensione ".flx".

•La compilazione del file di flusso

Dalla voce di menu "Compilatore" selezioniamo il file da compilare: il programma legge l'intero contenuto e, riga per riga, traduce le istruzioni nei corrispondenti codici midi. Il programma presenta una nuova finestra con diverse sezioni:

1) Nome del file
2) Moduli attivi
3) Libreria midi
4) Analisi oggetti
5) Compilazione
6) Codici midi decimali
7) Analisi midifile
8) Report
9) Partitura prospettica
10) Codici midi ascii
11) Midi file
12) Errori

Nella prima sezione, "→ File di flusso", viene visualizzato il nome del file in compilazione. Per motivi di sicurezza, sono state adottate soluzioni a volte macchinose, ma necessarie, per evitare il non corretto uso delle varie funzioni. In questo caso, si è deciso di omettere il path completo del file ritenendo il solo nome più che sufficiente all'individuazione dello stesso.

Nella sezione 2, "→ Attivo moduli", troviamo l'elenco completo dei moduli operativi disponibili: se sono visibili nella finestra sono stati riconosciuti come corretti e operativi. I moduli sono in "open source", possono quindi essere scritti da qualsiasi utente (vedi: → Protocollo-Moduli).

Nella sezione 3 abbiamo una lista dei moduli "open source", delle classi e delle funzioni (private) utilizzate nella scrittura del programma. La finestra 4 scompone eventuali oggetti presenti nel flusso (nel nostro esempio nessuno) mostrandoci base e derivati.

Nella finestra 5 abbiamo il "log" della compilazione: viene riportato il file originale e la successiva interpretazione (moduli in codici / oggetti in moduli e codici). Il nostro esempio contiene solo codici che vengono interpretati e compilati immediatamente in sezione 6, codici midi decimali, utili per una lettura "umana" del midi file. Gli utenti più esperti avranno immediatamente riconosciuto la sequenza 77,84,104,100 (MThd) che apre qualsiasi protocollo midi SMF.

Il midifile viene quindi analizzato (sez. 7) e decodificato in un formato "umano": questi codici verranno utilizzati in analisi (per ora non sono attivi i moduli relativi). In sequenza abbiamo un id progressivo, il delta-time (dt), il progressivo interno in base all'esecuzione (p), il canale di riferimento (ch), il nome della nota in notazione anglosassone, alterazione e ottava (n), l'ottava (ott), il codice decimale (cod), il codice della nota in numerazione mod. 12 (mod), il valore dinamico (v), la durata (espressa in tick) sulla base della riga 5 del file di flusso (dur).

Nella sezione 8 possiamo effettuare il download di un report in pdf dell'intera compilazione (Download report). Il report presenta, in forma testuale, i dati visualizzati nelle varie sezioni esclusa, per ora, la partitura; disponibile, quest'ultima, nella sezione 9. La partitura viene generata utilizzando le specifiche memorizzate nella voce di menu "Moduli grafici - Partitura prospettica", in particolare quelle relative al file di default (definito dall'utente). Per la modifica dei dati occorre avere i cookie abilitati alla scrittura.

Seguono quindi, nella sez. 10, la serie dei codici ASCII che costituiscono il midifile e, nella sezione 11, il pulsante di download del file midi (in formato .zip). Inizialmente il programma creava una cartella salvando tutti i file relativi al suo interno con tutti i problemi che ciò comporta in termini di sicurezza. Nella sezione 12 eventuali errori (se rilevati) vengono evidenziati in rosso. Attualmente non è stata implementata alcuna routine di gestione degli errori: file errati vengono semplicemente ignorati o producono partiture e midi file inutilizzabili (in casi estremi è anche possibile il blocco del programma).

Gli utenti possono, oltre che scrivere file di flusso, produrre MODULI, OGGETTI (accompagnati dalla descrizione operativa) e PARTITURE, ovvero tecniche grafiche per la generazione delle stesse. Attualmente sto lavorando ad un modulo per la gestione del colore mediante librerie GD (ma il tempo è veramente tiranno!).

In conclusione, dal testo risulta evidente che non solo i moduli, gli oggetti e le partiture possono essere generati da script ma lo stesso file di flusso potrebbe essere "assemblato" da algoritmi specifici. Ciò che mi interessa è proprio lo sviluppo di tali algoritmi, non in senso "tecnico" (l'informatica è mezzo e non fine) ma decisamente estetico: nella terza sezione del manuale (Oggetti), le pagine sono ancora bianche perchè tuttora in fase progettuale. Il linguaggio è dedicato alla ricerca, non certo alla produzione o al live: per comprendere pienamente il senso dello studio vi invito, pertanto, alla lettura di "Teoria dei Sonemi" disponibile in → iTunes U.