1 @c -*- coding: utf-8; mode: texinfo; documentlanguage: it -*-
4 Translation of GIT committish: 7ba0a22641cb0c7f5949d66a06d1e2e1fd0b3033
6 When revising a translation, copy the HEAD committish of the
7 version that you are working on. For details, see the Contributors'
8 Guide, node Updating translation committishes..
13 @node Consigli su come scrivere i file
14 @chapter Consigli su come scrivere i file
15 @translationof Suggestions for writing files
17 Ora puoi iniziare a scrivere file di input di LilyPond più grandi --
18 non più i piccoli esempi del tutorial, ma pezzi completi.
19 Ma qual è il modo migliore di farlo?
21 Finché LilyPond comprende i file di input e produce l'output che
22 desideri, non importa quale aspetto abbiano i file di input. Tuttavia,
23 ci sono altri aspetti da tenere a mente quando si scrivono
24 file di input di LilyPond.
27 @item Che fare in caso di errore? La struttura data a un file LilyPond può
28 rendere l'individuazione di certi tipi di errore più facile (o più difficile).
30 @item Che fare se vuoi inviare i tuoi file di input a qualcuno? E se decidi di
31 modificare i tuoi file di input dopo qualche anno? Alcuni file di input di
32 LilyPond sono comprensibili a prima vista; altri ti possono lasciare a grattarti
35 @item Che fare se vuoi aggiornare il tuo file per poterlo usare con una
36 versione più recente di LilyPond? Con l'evolversi di LilyPond, la sintassi di
37 input si trova soggetta a occasionali cambiamenti. Alcune modifiche possono
38 essere fatte in automatico con @code{convert-ly}, ma altre potrebbero richiedere
39 un intervento manuale. I file di input di LilyPond possono essere strutturati
40 in moda da essere poi aggiornati in modo più semplice (o più difficile).
46 * Scrivere musica esistente::
48 * Risoluzione dei problemi::
53 @node Consigli generali
54 @section Consigli generali
55 @translationof General suggestions
57 Ecco alcuni consigli che possono aiutarti a evitare o risolvere
61 @item @strong{Includi il numero di @code{\version} in ogni file}. Nota che tutti
62 i modelli contengono l'informazione su @code{\version}. Si consiglia vivamente
63 di includere sempre @code{\version}, non importa quanto piccolo possa essere
64 il file. L'esperienza personale insegna come sia frustrante cercare di ricordare
65 quale versione di LilyPond si usava alcuni anni prima! @command{convert-ly}
66 richiede che si dichiari la versione di LilyPond utilizzata.
68 @item @strong{Includi i controlli}: @ruser{Bar and bar number checks},
69 @ruser{Octave checks}. Includendo i controlli ogni tanto, se fai
70 un errore lo puoi individuare più rapidamente. Cosa si intende per
71 @q{ogni tanto}? Dipende dalla complessità della musica. Se la musica
72 è molto semplice, anche solo una volta o due. Se la musica è molto
73 complessa, a ogni battuta.
75 @item @strong{Una battuta per ogni linea di testo}. Se c'è qualcosa di
76 complicato, nella musica stessa o nell'output che desideri, di solito è
77 preferibile scrivere una sola battuta per linea. Risparmiare spazio sullo
78 schermo concentrando otto battute per ogni riga non è affatto conveniente
79 se poi devi fare il @q{debug} dei file di input.
81 @item @strong{Inserisci dei commenti nei file di input}. Puoi usare i numeri
82 di battuta (ogni tanto) o dei riferimenti ai temi musicali
83 (@q{secondo tema nei violini,} @q{quarta variazione,} etc.). Potresti non
84 aver bisogno dei commenti mentre scrivi il brano la prima volta, ma se due
85 o tre anni dopo vuoi cambiare qualcosa o se vuoi dare il sorgente a un amico,
86 sarà molto più difficile capire le tue intenzioni e la struttura del file
87 se mancano i commenti.
89 @item @strong{Indenta le parentesi graffe}. Molti problemi sono causati
90 da mancata corrispondenza tra le quantità di @code{@{} e di @code{@}}.
92 @item @strong{Esplicita le durate} all'inizio delle sezioni e delle
93 variabili. Se specifichi @code{c4 d e} all'inizio di una frase
94 (invece di @code{c d e} soltanto) puoi evitare l'insorgere di problemi
95 al momento di rimetter mano alla musica.
97 @item @strong{Separa le modifiche manuali (tweak)} dalle definizioni
98 musicali. Vedi @rlearning{Ridurre l’input grazie a variabili e funzioni}, e
99 @rlearning{Style sheets}.
104 @node Scrivere musica esistente
105 @section Scrivere musica esistente
106 @translationof Typesetting existing music
108 Se stai riportando della musica da una partitura esistente (ovvero il brano
109 contenuto in uno spartito già scritto),
113 @item Inserisci in LilyPond le note del manoscritto (la copia fisica della
114 musica) un sistema alla volta (ma sempre una battuta per linea di testo),
115 e controlla ogni sistema completato. Puoi usare le proprietà
116 @code{showLastLength} o @code{showFirstLength} per velocizzare
117 l'elaborazione -- vedi @ruser{Skipping corrected music}.
119 @item Definisci @code{mBreak = @{ \break @}} e inserisci @code{\mBreak}
120 nel file di input ogni volta che nel manoscritto c'è un a capo. In questo
121 modo è più semplice confrontare la musica generata da LilyPond con quella
122 originale. Quando hai finito la revisione della partitura, puoi
123 definire @code{mBreak = @{ @}} per eliminare tutte queste interruzioni di
124 riga. Così LilyPond potrà inserire le interruzioni dove ritiene stiano
127 @item Quando si inserisce una parte per strumento traspositore all'interno
128 di una variabile, è consigliabile racchiudere le note tra parentesi graffe
131 \transpose c altezza-naturale @{...@}
135 (dove @code{altezza-naturale} corrisponde all'intonazione di base dello
136 strumento) così che la musica contenuta nella variabile sia effettivamente
137 scritta in Do. La puoi presentare trasposta quando la variabile viene usata,
138 se necessario, ma potresti non desiderarlo (ad esempio quando si stampa una
139 partitura in intonazione reale, quando si traspone una parte per trombone
140 dalla chiave di Sol alla chiave di basso, etc.). Errori nelle trasposizioni
141 sono meno probabili se tutta la musica contenuta nelle variabili è ad
144 Inoltre, trasponi sempre in relazione al Do. Questo significa che le uniche
145 altre tonalità che userai saranno le altezze naturali degli strumenti - bes
146 per una tromba in Si bemolle, aes per un clarinetto in La bemolle, etc.
151 @node Grandi progetti
152 @section Grandi progetti
153 @translationof Large projects
155 Quando si lavora a un grande progetto, definire una struttura chiara nel
156 file di input diventa vitale.
160 @item @strong{Usa una variabile per ogni voce}, con un minimo di
161 struttura nella definizione. La struttura della sezione
162 @code{\score} è la parte più probabilmente soggetta a cambiamenti;
163 è invece molto improbabile che la definizione di @code{violin} cambi
164 in una nuova versione di LilyPond.
167 violin = \relative c'' @{
180 @item @strong{Separa le modifiche manuali (tweak) dalle definizioni musicali}. Questo
181 punto è stato menzionato prima; nei grandi progetti diventa di vitale
182 importanza. Potrebbe essere necessario modificare la definizione
183 di @code{fthenp}, ma si dovrebbe farlo una volta sola e senza toccare
184 niente in @code{violin}.
188 \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
189 violin = \relative c'' @{
197 @node Risoluzione dei problemi
198 @section Risoluzione dei problemi
199 @translationof Troubleshooting
201 Prima o poi ti capiterà di scrivere un file che LilyPond non
202 riesce a compilare. I messaggi inviati da LilyPond potrebbero aiutarti
203 a trovare l'errore, ma in molti casi sarà necessario fare qualche ricerca
204 per individuare l'origine del problema.
206 Gli strumenti più potenti a questo riguardo sono il commento della
207 linea singola (indicato da @code{%}) e il commento di blocco
208 (indicato da @code{%@{ ... %@}}). Se non sai dove sia il problema,
209 inizia col commentare ampie parti del file di input. Dopo aver commentato
210 una sezione, prova a compilare di nuovo il file. Se funziona, allora il
211 problema deve trovarsi nella parte che hai appena commentato. Se non
212 funziona, continua a commentare il materiale finché non ottieni un codice
215 Nel caso estremo, potresti finire con soltanto
229 (in altre parole, un file senza musica)
231 Se dovesse succedere, non rinunciare. Decommenta un pezzetto -- ad esempio,
232 la parte di basso -- e vedi se funziona. Se non funziona,
233 allora commenta tutta la musica del basso (ma lascia
234 @code{\bass} in @code{\score} non commentato).
237 bass = \relative c' @{
245 Ora inizia a decommentare mano a mano la parte di
246 @code{bass} finché non trovi la linea che causa il problema.
248 Un'altra tecnica di debug molto utile consiste nel creare
249 @rweb{Esempi minimi}.
252 @node Make e Makefile
253 @section Make e Makefile
254 @translationof Make and Makefiles
259 Tutte le piattaforme su cui Lilypond può essere installato supportano un
260 software chiamato @code{make}. Questo software legge un file speciale chiamato
261 @code{Makefile} che definisce quali file dipendono da quali altri e quali
262 comandi occorra dare al sistema operativo per produrre un file da un
263 altro. Ad esempio Makefile può spiegare come generare
264 @file{ballad.pdf} e @file{ballad.midi} da @file{ballad.ly} eseguendo
267 In alcune situazioni, è una buona idea creare un @code{Makefile}
268 per il proprio progetto, per proprio comodo o come cortesia
269 per quanti altri possano avere accesso ai file sorgente.
270 Questo vale per i progetti molto ampi con tanti file inclusi e
271 diverse opzioni di output (ad esempio, partitura completa, parti, partitura
272 del direttore, riduzione per pianoforte, etc.) o per progetti che
273 richiedono comandi difficili per la compilazione (come i progetti che
274 usano @code{lilypond-book}). I Makefile variano molto in complessità
275 e flessibilità, in base alle necessità e alle abilità degli autori.
276 Il programma GNU Make è installato nelle distribuzioni GNU/Linux
277 e su MacOS X ed è disponibile anche per Windows.
279 Si veda il @strong{Manuale di GNU Make} per conoscere in dettaglio l'uso di
280 @code{make}, dato che quel che segue dà solo un'idea delle sue potenzialità.
282 I comandi per definire delle regole in un Makefile cambiano in base
283 alla piattaforma; ad esempio le varie distribuzioni di Linux e
284 MacOS usano @code{bash}, mentre Windows usa @code{cmd}. Nota che su
285 MacOS X è necessario configurare il sistema per usare l'interprete da linea
286 di comando. Di seguito alcuni Makefile di esempio, con versioni sia per
287 Linux/MacOS sia per Windows.
289 Il primo esempio è per una composizione per orchestra in quattro
290 movimenti e presenta una directory strutturata come segue:
307 | |-- symphony-cello.ly
308 | |-- symphony-horn.ly
309 | |-- symphony-oboes.ly
310 | |-- symphony-viola.ly
311 | |-- symphony-violinOne.ly
312 | `-- symphony-violinTwo.ly
322 I file @file{.ly} nelle directory @file{Scores} e
323 @file{Parts} prendono le note dai file @file{.ily}
324 nella directory @file{Notes}:
327 %%% inizio del file "symphony-cello.ly"
328 \include ../definitions.ily
329 \include ../Notes/cello.ily
332 Il Makefile avrà i target di @code{score} (l'intero brano in partitura
333 completa), @code{movements} (singoli movimenti in partitura completa),
334 e @code{parts} (singole parti per i musicisti). C'è anche un
335 target @code{archive} che creerà un archivio compresso dei file sorgenti,
336 utile per la condivisione via web o email. Ecco un esempio di
337 Makefile per GNU/Linux e MacOS X. Dovrebbe essere salvato col
338 nome @code{Makefile} nella directory principale del progetto:
340 @warning{Quando si definisce un target o una regola di pattern, le
341 linee successive devono iniziare con i tabulatori, non con gli spazi.}
344 # Il prefisso al nome dei file di output
346 # Determinazione del numero dei processori
347 CPU_CORES=`cat /proc/cpuinfo | grep -m1 "cpu cores" | sed s/".*: "//`
348 # Il comando per eseguire lilypond
349 LILY_CMD = lilypond -ddelete-intermediate-files \
350 -dno-point-and-click -djob-count=$(CPU_CORES)
352 # I suffissi usati in questo Makefile.
353 .SUFFIXES: .ly .ily .pdf .midi
355 # I file di input e di output vengono cercati nelle directory elencate
356 # nella variabile VPATH. Tutte queste sono sottodirectory della directory
357 # corrente (assegnata dalla variabile `CURDIR' di GNU make).
364 # La regola di pattern per creare i file PDF e MIDI da un file di input LY.
365 # I file di output .pdf vengono messi nella sottodirectory `PDF', mentre i file
366 # .midi vanno nella sottodirectory `MIDI'.
368 $(LILY_CMD) $<; \ # questa linea inizia con una tabulazione
369 if test -f "$*.pdf"; then \
372 if test -f "$*.midi"; then \
373 mv "$*.midi" MIDI/; \
384 # Le dipendenze dei movimenti.
385 $(piece)I.pdf: $(piece)I.ly $(notes)
386 $(piece)II.pdf: $(piece)II.ly $(notes)
387 $(piece)III.pdf: $(piece)III.ly $(notes)
388 $(piece)IV.pdf: $(piece)IV.ly $(notes)
390 # Le dipendenze della partitura completa.
391 $(piece).pdf: $(piece).ly $(notes)
393 # Le dipendenze delle parti.
394 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
395 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
396 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
397 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
398 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
399 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
401 # Lanciare `make score' per generare la partitura completa di tutti i quattro
402 # movimenti in un unico file.
406 # Lanciare `make parts' per generare tutte le parti.
407 # Lanciare `make foo.pdf' per generare la parte per lo strumento `foo'.
408 # Esempio: `make symphony-cello.pdf'.
410 parts: $(piece)-cello.pdf \
411 $(piece)-violinOne.pdf \
412 $(piece)-violinTwo.pdf \
417 # Lanciare `make movements' per generare i file per i
418 # quattro movimenti separatamente.
420 movements: $(piece)I.pdf \
425 all: score parts movements
428 tar -cvvf stamitz.tar \ # questa linea inizia con una tabulazione
429 --exclude=*pdf --exclude=*~ \
430 --exclude=*midi --exclude=*.tar \
435 Ci sono alcune complicazioni specifiche della piattaforma Windows. Dopo aver
436 scaricato e installato GNU Make per Windows, bisogna impostare il percorso
437 corretto nelle variabili d'ambiente di sistema perché la
438 shell DOS possa trovare il programma Make. Per farlo, clicca col tasto destro
439 del mouse su "My Computer," poi scegli @code{Proprietà} e
440 @code{Avanzate}. Clicca su @code{Variabili di ambiente}, e poi nel
441 pannello @code{Variabili di Sistema}, nella sezione @code{Percorso}, clicca su
442 @code{modifica} e aggiungi il percorso al file eseguibile GNU Make, che
443 avrà un aspetto simile:
446 C:\Program Files\GnuWin32\bin
449 Lo stesso Makefile deve essere modificato per gestire diversi comandi
450 shell e gli spazi che sono presenti in alcune directory predefinite
451 di sistema. Il target @code{archive} target viene tolto perché Windows
452 non ha il comando @code{tar}; inoltre Windows ha una diversa estensione
453 predefinita per i file midi.
457 ## VERSIONE DI WINDOWS
460 LILY_CMD = lilypond -ddelete-intermediate-files \
461 -dno-point-and-click \
462 -djob-count=$(NUMBER_OF_PROCESSORS)
464 #get the 8.3 name of CURDIR (workaround for spaces in PATH)
465 workdir = $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
468 .SUFFIXES: .ly .ily .pdf .mid
477 $(LILY_CMD) $< # questa linea inizia con una tabulazione
478 if exist "$*.pdf" move /Y "$*.pdf" PDF/
479 if exist "$*.mid" move /Y "$*.mid" MIDI/
491 $(piece)I.pdf: $(piece)I.ly $(notes)
492 $(piece)II.pdf: $(piece)II.ly $(notes)
493 $(piece)III.pdf: $(piece)III.ly $(notes)
494 $(piece)IV.pdf: $(piece)IV.ly $(notes)
496 $(piece).pdf: $(piece).ly $(notes)
498 $(piece)-cello.pdf: $(piece)-cello.ly cello.ily
499 $(piece)-horn.pdf: $(piece)-horn.ly horn.ily
500 $(piece)-oboes.pdf: $(piece)-oboes.ly oboe.ily
501 $(piece)-viola.pdf: $(piece)-viola.ly viola.ily
502 $(piece)-violinOne.pdf: $(piece)-violinOne.ly violinOne.ily
503 $(piece)-violinTwo.pdf: $(piece)-violinTwo.ly violinTwo.ily
509 parts: $(piece)-cello.pdf \
510 $(piece)-violinOne.pdf \
511 $(piece)-violinTwo.pdf \
517 movements: $(piece)I.pdf \
522 all: score parts movements
526 Il Makefile seguente è per un documento @command{lilypond-book} fatto con
527 LaTeX. Questo progetto ha un indice, dunque il comando @command{latex} deve
528 essere eseguito due volte per aggiornare i collegamenti. I file di output
529 sono tutti salvati nella directory @code{out} per i file .pdf e nella directory
530 @code{htmlout} per i file html.
539 LILYBOOK_PDF=lilypond-book --output=$(OUTDIR) --pdf $(FILE).lytex
540 LILYBOOK_HTML=lilypond-book --output=$(WEBDIR) $(FILE).lytex
541 PDF=cd $(OUTDIR) && pdflatex $(FILE)
542 HTML=cd $(WEBDIR) && latex2html $(FILE)
543 INDEX=cd $(OUTDIR) && makeindex $(FILE)
544 PREVIEW=$(VIEWER) $(OUTDIR)/$(FILE).pdf &
549 $(LILYBOOK_PDF) # inizia con una tabulazione
550 $(PDF) # inizia con una tabulazione
551 $(INDEX) # inizia con una tabulazione
552 $(PDF) # inizia con una tabulazione
553 $(PREVIEW) # inizia con una tabulazione
556 $(LILYBOOK_HTML) # inizia con una tabulazione
557 $(HTML) # inizia con una tabulazione
558 cp -R $(WEBDIR)/$(FILE)/ ./ # inizia con una tabulazione
559 $(BROWSER) $(FILE)/$(FILE).html & # inizia con una tabulazione
562 cp $(OUTDIR)/$(FILE).pdf $(FILE).pdf # inizia con una tabulazione
565 rm -rf $(OUTDIR) # inizia con una tabulazione
568 rm -rf $(WEBDIR) # inizia con una tabulazione
571 tar -cvvf myproject.tar \ # inizia questa linea con una tabulazione
573 --exclude=htmlout/* \
574 --exclude=myproject/* \
581 @c TODO: make this thing work on Windows
583 Il Makefile precedente non funziona su Windows. Un'alternativa per
584 gli utenti Windows consiste nel creare un semplice file batch
585 contenente i comandi per la compilazione. Questo file non terrà
586 traccia delle dipendenze come fa invece un Makefile, ma almeno riduce
587 il processo di compilazione a un solo comando. Salva il codice
588 seguente come @command{build.bat} o @command{build.cmd}.
589 Il file batch può essere eseguito nel prompt DOS o semplicemente con
590 un doppio clic sulla sua icona.
593 lilypond-book --output=out --pdf myproject.lytex
599 copy out\myproject.pdf MyProject.pdf
606 @ref{Uso da linea di comando},