X-Git-Url: https://git.donarmstrong.com/?a=blobdiff_plain;f=Documentation%2Fit%2Fusage%2Fsuggestions.itely;h=e5de7e612d33fcfac2f7c6477e97e84788e403a0;hb=2fef7b7eb7ac5d7a2ed237bf22a6ec6fe5d946d9;hp=933bfbce3ad80b64112834ae6baafe1df8cc8603;hpb=32a34dcef0c0041c6d62677487a380b5c8b85712;p=lilypond.git diff --git a/Documentation/it/usage/suggestions.itely b/Documentation/it/usage/suggestions.itely index 933bfbce3a..e5de7e612d 100644 --- a/Documentation/it/usage/suggestions.itely +++ b/Documentation/it/usage/suggestions.itely @@ -1,14 +1,14 @@ @c -*- coding: utf-8; mode: texinfo; documentlanguage: it -*- @ignore - Translation of GIT committish: de9ddc8183a93f28d167af8f195be95e5fbc91b9 + Translation of GIT committish: 8c1840ca28a05b3dad8d595e04d03779ba0a286a 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 @@ -54,49 +54,91 @@ in moda da essere poi aggiornati in modo più semplice (o più difficile). @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{Aggiornare i file con 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 @@ -114,7 +156,7 @@ contenuto in uno spartito già scritto), musica) un sistema alla volta (ma sempre una battuta per linea di testo), e controlla ogni sistema completato. Puoi usare le proprietà @code{showLastLength} o @code{showFirstLength} per velocizzare -l'elaborazione -- vedi @ruser{Skipping corrected music}. +l'elaborazione -- vedi @ruser{Saltare la musica già corretta}. @item Definisci @code{mBreak = @{ \break @}} e inserisci @code{\mBreak} nel file di input ogni volta che nel manoscritto c'è un a capo. In questo @@ -128,7 +170,7 @@ meglio. di una variabile, è consigliabile racchiudere le note tra parentesi graffe @example -\transpose c altezza-naturale @{...@} +\transpose c altezza-naturale @{@dots{}@} @end example @noindent @@ -164,10 +206,10 @@ struttura nella definizione. La struttura della sezione 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 @{ @@ -186,8 +228,8 @@ niente in @code{violin}. @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 @@ -205,7 +247,7 @@ per individuare l'origine del problema. 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 @@ -234,9 +276,9 @@ allora commenta tutta la musica del basso (ma lascia @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 %@} @} @@ -256,13 +298,13 @@ Un'altra tecnica di debug molto utile consiste nel creare @cindex makefile @cindex make -Tutte le piattaforme su cui Lilypond può essere installato supportano un +Tutte le piattaforme su cui LilyPond può essere installato supportano un software chiamato @code{make}. Questo software legge un file speciale chiamato @code{Makefile} che definisce quali file dipendono da quali altri e quali comandi occorra dare al sistema operativo per produrre un file da un altro. Ad esempio Makefile può spiegare come generare @file{ballad.pdf} e @file{ballad.midi} da @file{ballad.ly} eseguendo -Lilypond. +LilyPond. In alcune situazioni, è una buona idea creare un @code{Makefile} per il proprio progetto, per proprio comodo o come cortesia @@ -280,11 +322,11 @@ Si veda il @strong{Manuale di GNU Make} per conoscere in dettaglio l'uso di @code{make}, dato che quel che segue dà solo un'idea delle sue potenzialità. I comandi per definire delle regole in un Makefile cambiano in base -alla piattaforma; ad esempio le varie distribuzioni di Linux e +alla piattaforma; ad esempio le varie distribuzioni di GNU/Linux e MacOS usano @code{bash}, mentre Windows usa @code{cmd}. Nota che su MacOS X è necessario configurare il sistema per usare l'interprete da linea di comando. Di seguito alcuni Makefile di esempio, con versioni sia per -Linux/MacOS sia per Windows. +GNU/Linux/MacOS sia per Windows. Il primo esempio è per una composizione per orchestra in quattro movimenti e presenta una directory strutturata come segue: