@c -*- coding: utf-8; mode: texinfo; documentlanguage: it -*-
@ignore
- Translation of GIT committish: 26a079ca2393d053315ef8dbef626c897dc9645a
+ Translation of GIT committish: d36171e34d236d890f5dc511b895037188c6c7cb
When revising a translation, copy the HEAD committish of the
version that you are working on. For details, see the Contributors'
Guide, node Updating translation committishes..
@end ignore
-@c \version "2.16.0"
+@c \version "2.19.21"
@node Consigli su come scrivere i file
@chapter Consigli su come scrivere i file
@section Consigli generali
@translationof General suggestions
-Ecco alcuni consigli che possono aiutarti a evitare o risolvere
-i problemi:
+Ecco alcuni consigli che possono aiutare a evitare (e risolvere) i
+problemi più comuni in fase di scrittura:
@itemize
-@item @strong{Includi il numero di @code{\version} in ogni file}. Nota che tutti
-i modelli contengono l'informazione su @code{\version}. Si consiglia vivamente
-di includere sempre @code{\version}, non importa quanto piccolo possa essere
-il file. L'esperienza personale insegna come sia frustrante cercare di ricordare
-quale versione di LilyPond si usava alcuni anni prima! @command{convert-ly}
-richiede che si dichiari la versione di LilyPond utilizzata.
-
-@item @strong{Includi i controlli}: @ruser{Bar and bar number checks},
-@ruser{Octave checks}. Includendo i controlli ogni tanto, se fai
-un errore lo puoi individuare più rapidamente. Cosa si intende per
-@q{ogni tanto}? Dipende dalla complessità della musica. Se la musica
-è molto semplice, anche solo una volta o due. Se la musica è molto
-complessa, a ogni battuta.
-
-@item @strong{Una battuta per ogni linea di testo}. Se c'è qualcosa di
-complicato, nella musica stessa o nell'output che desideri, di solito è
-preferibile scrivere una sola battuta per linea. Risparmiare spazio sullo
-schermo concentrando otto battute per ogni riga non è affatto conveniente
-se poi devi fare il @q{debug} dei file di input.
-
-@item @strong{Inserisci dei commenti nei file di input}. Puoi usare i numeri
-di battuta (ogni tanto) o dei riferimenti ai temi musicali
-(@q{secondo tema nei violini,} @q{quarta variazione,} etc.). Potresti non
-aver bisogno dei commenti mentre scrivi il brano la prima volta, ma se due
-o tre anni dopo vuoi cambiare qualcosa o se vuoi dare il sorgente a un amico,
-sarà molto più difficile capire le tue intenzioni e la struttura del file
-se mancano i commenti.
-
-@item @strong{Indenta le parentesi graffe}. Molti problemi sono causati
-da mancata corrispondenza tra le quantità di @code{@{} e di @code{@}}.
-
-@item @strong{Esplicita le durate} all'inizio delle sezioni e delle
-variabili. Se specifichi @code{c4 d e} all'inizio di una frase
-(invece di @code{c d e} soltanto) puoi evitare l'insorgere di problemi
-al momento di rimetter mano alla musica.
-
-@item @strong{Separa le modifiche manuali (tweak)} dalle definizioni
-musicali. Vedi @rlearning{Ridurre l'input grazie a variabili e funzioni}, e
-@rlearning{Style sheets}.
+@item @strong{Includere sempre il numero di @code{\version} in ogni file di input},
+non importa quanto piccolo possa essere il file. Ciò impedisce di dover
+ricordare con quale versione di LilyPond è stato creato il file ed è
+importante soprattutto per @ref{Updating files with convert-ly} (che ha
+bisogno della dichiarazione @code{\version}); o quando si inviano i file
+di input a altri utenti (per esempio, quando si chiede aiuto nelle mailing
+list). Nota che tutti i modelli contengono l'informazione su @code{\version}.
+
+@item
+@strong{Scrivere ciascuna battuta su una singola riga del file di input}. Ciò
+semplifica molto l'analisi dei problemi del file di input.
+
+@item
+@strong{Inserire i @ruser{Controlli di battuta e del numero di battuta} e
+i @ruser{Controlli di ottava}}. Inserendo @q{controlli} di questo tipo nei
+file di input, si può individuare un errore più rapidamente. Quanto spesso
+aggiungere i controlli dipende dalla complessità della musica da scrivere. Per
+composizioni semplici, aggiungere controlli in pochi punti strategici può essere
+sufficiente, ma per musica più complessa, con molte voci e/o righi, è consigliabile
+inserire i controlli dopo ogni battuta.
+
+@item
+@strong{Inserire commenti nei file di input}. Riferimenti a temi musicali
+(@q{secondo tema nei violini,} @q{quarta variazione,} etc.) o numeri di battuta
+inseriti come commenti rendono molto più semplice la lettura del file di input,
+specialmente se occorre modificare qualcosa successivamente o passare i file
+di input di LilyPond a un'altra persona.
+
+@item
+@strong{Aggiungere durate esplicite all'inizio delle @q{sezioni}}.
+Per esempio, @code{c4 d e} invece di @code{c d e f} può semplificare il
+riarrangiamento della musica in un momento successivo.
+
+@item
+@strong{Imparare a allineare e indentare le parentesi e la musica parallela}.
+Molti problemi sono spesso causati da parentesi @q{mancanti}. Indentare
+chiaramente le parentesi di @q{apertura} e di @q{chiusura} (o gli indicatori
+@code{<<} e @code{>>}) aiuta a evitare tali problemi. Per esempio,
+
+@example
+\new Staff @{
+ \relative @{
+ r4 g'8 g c8 c4 d |
+ e4 r8 |
+ % Sezione Ossia
+ <<
+ @{ f8 c c | @}
+ \new Staff @{
+ f8 f c |
+ @}
+ >>
+ r4 |
+ @}
+@}
+@end example
+
+@noindent
+è molto più semplice da leggere di
+
+@example
+\new Staff @{ \relative @{ r4 g'8 g c4 c8 d | e4 r8
+% Sezione Ossia
+<< @{ f8 c c @} \new Staff @{ f8 f c @} >> r4 | @} @}
+@end example
+
+@item
+@strong{Tenere separato il contenuto musicale dallo stile} mettendo gli
+@code{\override} nel blocco @code{\layout}:
+
+@example
+\score @{
+ @var{@dots{}music@dots{}}
+ \layout @{
+ \override TabStaff.Stemstencil = ##f
+ @}
+@}
+@end example
+
+Ciò non creerà un nuovo contesto ma sarà applicato quando ne viene creato
+uno. Vedi anche @rlearning{Ridurre l'input grazie a variabili e funzioni} e
+@rlearning{Fogli di stile}.
@end itemize
di una variabile, è consigliabile racchiudere le note tra parentesi graffe
@example
-\transpose c altezza-naturale @{...@}
+\transpose c altezza-naturale @{@dots{}@}
@end example
@noindent
in una nuova versione di LilyPond.
@example
-violin = \relative c'' @{
-g4 c'8. e16
+violin = \relative @{
+g'4 c'8. e16
@}
-...
+@dots{}
\score @{
\new GrandStaff @{
\new Staff @{
@example
fthenp = _\markup@{
\dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
-violin = \relative c'' @{
-g4\fthenp c'8. e16
+violin = \relative @{
+g'4\fthenp c'8. e16
@}
@end example
Gli strumenti più potenti a questo riguardo sono il commento della
linea singola (indicato da @code{%}) e il commento di blocco
-(indicato da @code{%@{ ... %@}}). Se non sai dove sia il problema,
+(indicato da @code{%@{ @dots{} %@}}). Se non sai dove sia il problema,
inizia col commentare ampie parti del file di input. Dopo aver commentato
una sezione, prova a compilare di nuovo il file. Se funziona, allora il
problema deve trovarsi nella parte che hai appena commentato. Se non
@code{\bass} in @code{\score} non commentato).
@example
-bass = \relative c' @{
+bass = \relative @{
%@{
- c4 c c c
+ c'4 c c c
d d d d
%@}
@}
projects / lilypond.git / blobdiff