Header¶
1. Definizione e ruolo dell’header¶
L’header è una sezione opzionale di un documento neumaRk, collocata all’inizio del file dopo la dichiarazione di versione.
Il suo scopo è contenere tutte le informazioni non strettamente musicali necessarie a:
- identificare il brano;
- contestualizzarlo (autore, stile, tempo, tonalità, ecc.);
- fornire indicazioni globali valide per l’intero documento.
In neumaRk l’header coincide integralmente con i metadati del file.
Non esistono metadati esterni, distribuiti o dichiarati altrove.
2. nrk:version e relazione con l’header¶
Ogni file neumaRk deve iniziare con una riga di versione nella forma:
nrk:
Esempio:
nrk:0.6
Caratteristiche:
- è obbligatoria;
- deve essere la prima riga del file;
- non fa parte dell’header.
Dopo la riga nrk:version possono comparire uno o più righi vuoti, seguiti da:
- un header, oppure
- direttamente dal primo datapack musicale.
3. Blocco di header e criterio di riconoscimento¶
3.1 Blocco iniziale¶
L’header, se presente, è costituito da un blocco di righe consecutive che:
- segue la riga
nrk:version(dopo eventuali righi vuoti); - precede qualsiasi datapack musicale;
- non contiene righe vuote.
L’header termina al primo rigo vuoto.
Il contenuto successivo è interpretato come datapack musicale.
3.2 Criterio “tutto o niente” (parsing conservativo)¶
Il blocco iniziale viene riconosciuto come header solo se tutte le sue righe sono valide secondo le regole di questo documento.
Se anche una sola riga:
- viola una regola sintattica;
- contiene un elemento non ammesso;
- oppure è interpretabile come riga musicale,
l’intero blocco viene classificato come non header.
In tal caso:
- il parsing dell’header fallisce;
- il blocco viene successivamente analizzato come datapack musicale.
Non è ammesso parsing parziale dell’header.
3.3 Principio di deduzione conservativa e anti-collisione¶
La deduzione implicita nell’header di neumaRk è governata da un principio fondamentale:
un elemento dell’header non deve mai poter essere confuso con un elemento musicale.
In particolare, una riga dell’header non deve collidere semanticamente con:
- una riga di note;
- una riga di accordi;
- una riga di markers;
- qualunque riga valida come datapack musicale.
Questo principio ha lo scopo di:
- evitare ambiguità strutturali;
- rendere il parsing affidabile;
- garantire che la deduzione non produca interpretazioni errate.
La deduzione è quindi conservativa:
- se una riga può essere interpretata sia come elemento di header sia come riga musicale, prevale l’interpretazione musicale;
- in tal caso, il parsing dell’header fallisce e il blocco viene trattato come datapack musicale.
La specifica non impone una grammatica formale completa per distinguere in modo assoluto header e contenuto musicale. Alcuni aspetti della deduzione possono dipendere da euristiche implementative, purché rispettino il principio di non-collisione e la strategia conservativa descritta.
Deduzione di style¶
Nella deduzione implicita dell’header, gli elementi testuali debolmente
tipizzati (come lo style) devono sempre evitare collisioni con elementi
strutturalmente più forti, quali Key, Meter e BPM.
5. Sintassi formale e sintassi informale¶
L’header supporta due modalità sintattiche: formale (esplicita) e informale (implicita).
5.1 Sintassi formale (esplicita)¶
Caratteristiche:
- uso di marcatori di riga espliciti;
- nessuna ambiguità sintattica;
- ordine delle righe arbitrario;
- ogni elemento occupa una riga dedicata.
È la modalità raccomandata per l’uso automatico.
5.2 Sintassi informale (implicita)¶
Caratteristiche:
- uso minimo o assente di marcatori;
- deduzione basata su contenuto e posizione;
- ordine delle righe vincolato;
- deduzione basata su regole conservative.
La sintassi informale privilegia la leggibilità e la scrittura rapida.
5.3 Precedenze¶
In caso di ambiguità o conflitto, prevale:
- la sintassi formale;
- le regole di posizione;
- la deduzione semantica;
- il fallimento del parsing dell’header.
6. Elementi ammessi nell’header¶
L’header riconosce esclusivamente i seguenti elementi:
- Titolo
- Credits
- Music by
- Lyrics by
- Arranger
- Transcriber
- Year
- Style
- Key
- Meter
- BPM
- Versions (solo forma esplicita
HV), vedi §11.6)
Tutti gli elementi sono opzionali.
Qualunque altro contenuto invalida l’intero header.
7. Marcatori di header¶
7.1 Definizione¶
I marcatori di header sono sequenze alfabetiche maiuscole seguite dal carattere ) e da uno spazio.
- il primo carattere è sempre
H; - la lunghezza varia da due a tre lettere.
7.2 Elenco dei marcatori¶
| Marcatore | Significato |
|---|---|
HT) |
Titolo |
HC) |
Credits generici |
HCM) |
Music by |
HCL) |
Lyrics by |
HCA) |
Arranger |
HCT) |
Transcriber |
HY) |
Year |
HS) |
Style |
HK) |
Key |
HM) |
Meter |
HB) |
BPM |
HV) |
Versions |
8. Titolo¶
8.1 Forma esplicita¶
- marcatore:
HT); - la prima riga
HT)è il titolo principale; sono ammesse righeHT)successive come titoli alternativi (alias di ricerca / per-lingua); - può contenere qualsiasi testo;
- può portare un tag lingua finale
[lingua](es.HT) No More Blues [EN]): forma sintattica[a-z]{2,3}(-regione)?, case-insensitive, strippato dal testo memorizzato. Associa quel titolo a una lingua — è il titolo tradotto per le edizioni di quella lingua (neumaRk_lyrics.md§8.8).
8.2 Forma implicita¶
In assenza di marcatore, il titolo:
- deve essere la prima riga dell’header;
- deve iniziare con una lettera maiuscola o un numero (dopo eventuali spazi);
- non deve essere interpretabile come riga musicale (note, accordi o markers).
La deduzione del titolo implicito è conservativa:
in caso di dubbio, l’header fallisce.
8.3 Titolo e credits sulla stessa riga¶
È ammesso indicare i credits sulla stessa riga del titolo solo in forma implicita.
In tal caso:
- i credits devono essere racchiusi tra parentesi tonde;
- non deve essere presente alcun marcatore esplicito sulla riga.
9. Credits¶
9.1 Ruolo¶
I credits identificano i contributori del brano.
9.2 Credits con marcatori specifici¶
Ogni elemento appare su una riga autonoma con marcatore dedicato:
HCM)— Music byHCL)— Lyrics byHCA)— ArrangerHCT)— Transcriber
L’ordine è arbitrario.
Nota (edizioni del testo).
HCL)indica l'autore del testo di default (edizione neutra). L'autore di un'edizione taggata si scrive col gruppo<…>sul bloccoLYRICS)(neumaRk_lyrics.md§8.8), non qui. Il vecchio credit per-linguaHCL) … [lingua]è rimosso: una rigaHCL)setta sempre e solo il lyricsBy primario.
9.3 Credits con marcatore generico¶
- marcatore:
HC); - una sola riga;
- parentesi opzionali;
- elementi separati da
/.
Assegnazione:
- primo elemento senza prefisso → Music by;
- secondo elemento senza prefisso → Lyrics by;
arr:→ Arranger;trans:→ Transcriber;- elementi successivi senza prefisso vengono ignorati.
9.4 Credits impliciti¶
Senza marcatore esplicito, i credits:
- devono essere racchiusi tra parentesi tonde;
- devono comparire su una sola riga;
- devono essere separati da
/.
Posizione ammessa:
- stessa riga del titolo;
- oppure riga immediatamente successiva.
10. Year, Style, Key, Meter, BPM¶
10.1 Regole comuni¶
- tutti opzionali;
- possono comparire solo dopo titolo e credits (se presenti);
- in forma esplicita l’ordine è arbitrario.
10.2 Forma esplicita¶
- ogni elemento su riga dedicata;
- uso del marcatore corrispondente.
10.3 Forma implicita¶
- possono essere combinati sulla stessa riga;
- nessun marcatore;
- riconoscimento basato su pattern.
11. Regole specifiche per elemento¶
11.1 Year¶
Indica l'anno di composizione: numero a 4 cifre compreso fra 1000 e 2999.
11.2 Style¶
Lo style è una descrizione testuale del carattere musicale del brano
(es. swing, bossa, latin, rock ballad).
Il valore dichiarato nell'header inizializza currentStyle e può
essere sovrascritto localmente in una qualsiasi misura tramite una
play directive (=Style,…) nella riga M) (vedi
neumaRk_play_directive.md).
Forma implicita¶
In forma implicita, lo style:
- deve iniziare con una lettera minuscola (dopo eventuali spazi);
- non deve collidere con pattern validi di:
- tonalità (
Key); - metro (
Meter); - tempo (
BPM).
Se una porzione di testo può essere interpretata sia come style sia come altro elemento strutturato dell’header, prevale sempre l’interpretazione strutturata.
In caso di ambiguità non risolvibile, la deduzione dello style fallisce senza invalidare l’intero header.
11.3 Key¶
Forma:
- nota
A–G; - alterazione
bo#opzionale; - maggiore implicita;
mo-per il minore.
Valore speciale:
X
che indica assenza di tonalità, politonalità o atonalità.
11.4 Meter¶
Forma frazionaria:
N/D
con N e D numeri interi di una o due cifre.
Esempi:
4/4
3/8
È consentita la forma estesa con suddivisione interna del numeratore (clave):
Esempio:
[3+3+2]/8
11.5 BPM¶
- numero intero di due o tre cifre;
- in forma implicita deve essere seguito da
BPM(case-insensitive); - in forma esplicita (
HB)) il suffisso è opzionale; - non sono ammessi numeri decimali.
Il valore dichiarato nell'header inizializza currentBPM e può essere
sovrascritto localmente in una qualsiasi misura tramite una play
directive (=…,Nbpm) o metric modulation (=…,figura=figura) nella
riga M) (vedi neumaRk_play_directive.md).
11.6 Versions¶
Dichiara le versioni alternative del brano. Disponibile solo in
forma esplicita (HV)).
HV) versions: [original, miles, jarrett] default=original
versions:parola chiave obbligatoria.- Lista di label fra parentesi quadre, separate da virgole.
default=<label>opzionale: specifica la variante mostrata alla prima apertura del brano.
Vedi neumaRk_versions.md per la spec completa dei blocchi
%%NAME … %%end e la semantica di sostituzione.
HV) è opzionale: in sua assenza le versioni sono dedotte
direttamente dai blocchi %%NAME "label" presenti nel documento.
12. Righe vietate e fallimento dell’header¶
Invalidano l’intero header:
- righe vuote;
- elementi non riconosciuti;
- righe interpretabili come datapack musicale;
- conflitti non risolvibili.
13. Esempi¶
My Song (John Doe / Jane Roe)
1998 Swing 120BPM 4/4 Dm
equivale a
HT) My Song
HC) John Doe / Jane Roe
HY) 1998
HS) Swing
HB) 120
HM) 4/4
HK) Dm
14. Note di implementazione¶
- il parsing dell’header è conservativo;
- non è prevista alcuna correzione automatica;
- non è previsto fallback parziale.