@c -*- coding: utf-8; mode: texinfo; documentlanguage: es -*-

@ignore
    Translation of GIT committish: 8677514240adc1b684c42680a624286f892486a6

    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.19.21"

@node Suggestions for writing files
@chapter Sugerencias para escribir archivos de entrada

En este momento está preparado para comenzar a escribir archivos
de LilyPond más grandes -- no sólo los pequeños ejemplos que
aparecen en el tutorial, sino piezas completas --. Pero ¿cómo debe
proceder para hacerlo?

En la medida en que LilyPond entienda sus archivos y produzca la
salida que usted pretendía, realmente no importa mucho qué aspecto
tengan sus archivos.  Sin embargo existen algunas otras cosas a
tener en cuenta cuando se escriben archivos de LilyPond.

@itemize
@item ¿Qué ocurre si comete un fallo?  La estructura de un archivo de
LilyPond puede hacer que ciertos errores se hagan más fáciles (o
más difíciles) de encontrar.

@item ¿Qué ocurre si quiere compartir sus archivos con otras
personas?  De hecho, ¿y si quiere alterar sus propios archivos
después de algunos años?  Algunos archivos de LilyPond se
comprenden a primera vista; otros pueden tenerle rascándose la
cabeza durante una hora.

@item ¿Qué ocurre si quiere actualizar su archivo de LilyPond para
poderlo usar con una versión más reciente del programa?

La sintaxis de la entrada se modifica de forma ocasional según
LilyPond se va perfeccionando.  Casi todos los cambios se pueden
hacer de forma automática con @code{convert-ly}, pero algunos
podrían necesitar de una ayuda manual.  Los archivos de LilyPond
se pueden estructurar para que sean más fáciles (o más difíciles)
de actualizar.

@end itemize


@node General suggestions
@section Sugerencias de tipo general

Presentamos algunas sugerencias que le pueden servir de ayuda para
evitar o corregir los problemas más comunes al realizar trabajos
de tipografía musical:

@itemize
@item
@strong{Incluya siempre el número de @code{\version} en los
archivos de entrada}, aun en los más pequeños.  Ello evita tener
que recordar para qué versión de LilyPond se creó el archivo y es
especialmente relevante al
@ref{Updating files with convert-ly} (una instrucción que
requiere que el enunciado @code{\version} esté presente); o si
está enviando código de entrada a otros usuarios (p.ej. si está
pidiendo ayuda en una de las listas de distribución de correo).
Observe que todas las plantillas de LilyPond contienen números de
@code{\version}.

@item
@strong{Escriba un compás de música en cada línea del código de
entrada}.  Esto hará que la búsqueda de problemas dentro de los
archivos de entrada sea mucho más sencilla.

@item
@strong{Inserte comprobaciones de compás, comprobaciones de
números de compás y comprobaciones de octava} (véase
@rnotationnamed{Bar and bar number checks,
Comprobación de compás y de número de compás} y
@rnotationnamed{Octave checks, Comprobación de octava}).  La
inclusión de códigos de comprobación de estos tipos será de ayuda
para localizar los errores mucho más rápidamente.  La frecuencia
con que añadir las comprobaciones dependerá de la complejidad de
la música que se está componiendo tipográficamente.  Para
composiciones sencillas, las comprobaciones añadidas en ciertos
puntos estratégicos dentro de la música pueden ser suficientes,
pero para música más compleja, con muchas voces y/o pentagramas,
sería mejor poner comprobaciones a cada compás.

@item
@strong{Inserte comentarios en el código de entrada}.  Las
referencias a los temas musicales (p.ej. @q{segundo tema en los
violines}, @q{cuarta variación}, etc.), o simplemente la inclusión
de los números de compás como compentarios, hará mucho más
sencilla la navegación por el archivo de entrada, especialmente si
más tarde se hace necesario alterar algo, o si estamos pasando los
archivos de entrada a otra persona.

@item
@strong{Escriba las duraciones explícitamente} al comienzo de las
@q{secciones}.  Por ejemplo, si especifica @code{c4 d e f} al
principio de una frase (en lugar de sólo @code{c d e f}) se puede
ahorrar problemas si reelabora la música más tarde.

@item
@strong{Aprenda a aplicar márgenes y sangrados a las llaves y a la
música paralela}.  Muchos problemas suelen estar producidos por
llaves de apertura o de cierre que faltan.  La aplicación clara de
sangrados a las llaves curvas de apertura y de cierre (o a los
indicadores @code{<<} y @code{>>}) será de ayuda para evitar tales
problemas.

Por ejemplo:

@example
\new Staff @{
  \relative @{
    r4 g'8 g c8 c4 d |
    e4 r8 |
    % sección de Ossia
    <<
      @{ f8 c c | @}
      \new Staff @{
        f8 f c |
      @}
    >>
    r4 |
  @}
@}
@end example

@noindent
es mucho más fácil de seguir que:

@example
\new Staff @{ \relative @{ r4 g'8 g c4 c8 d | e4 r8
% sección de Ossia
<< @{ f8 c c @} \new Staff @{ f8 f c @} >> r4 | @} @}
@end example


@item
@strong{Mantenga separados la música y el estilo} poniendo las
sobreescrituras dentro del bloque @code{\layout}:

@example
\score @{
  @var{@dots{}música@dots{}}
  \layout @{
   \override TabStaff.Stemstencil = ##f
 @}
@}
@end example

Esto no crea un contexto nuevo, sino que se aplicará en el momento
de crear uno.  Véase también
@rlearningnamed{Saving typing with variables and functions,
Ahorrar tecleo mediante variables y funciones} y
@rlearningnamed{Style sheets, Hojas de estilo}.

@end itemize


@node Typesetting existing music
@section Tipografiar música existente

Si está introduciendo música a partir de una partitura existente
(es decir, tipografiando una hoja de música ya impresa),

@itemize

@item Introduzca en LilyPond un sistema del manuscrito, o copia
física, de cada vez (pero mantenga la práctica de escribir un
compás por línea de texto), y compruebe cada sistema cuando lo
haya terminado.  Puede usar las propiedades @code{showLastLength}
o @code{showFirstLength} para acelerar el proceso (véase
@rnotationnamed{Skipping corrected music, Saltar la música
corregida}).

@item Defina @code{mBreak = @{ \break @}} e inserte @code{\mBreak}
dentro del archivo de entrada donde el manuscrito tenga un saldo
de línea.  De esta forma le resultará mucho más fácil comparar la
música de LilyPond con la original.  Cuando haya terminado de
revisar su partitura podrá definir @code{mBreak = @{ @}} para
quitar todos esos saltos de línea.  Así permitirá a LilyPond
colocar los saltos donde éste lo estime más oportuno.

@item Al escribir una parte para un instrumento transpositor
dentro de una variable, se recomienda que las notas estén
envueltas dentro de

@example
\transpose c altura-natural @{@dots{}@}
@end example

@noindent
(donde @code{altura-natural} es la afinación natural del
instrumento) de forma que la música dentro de la variable esté
realmente en Do mayor.  Después podemos volver a transportarlas en
sentido inverso cuando se utiliza la variable, si es necesario,
pero quizá no queramos hacerlo (p.ej., al imprimir una partitura
en afinación de concierto, al convertir una parte de trombón de
clave de Sol a clave de Fa, etc.).  Es menos probable cometer
errores en los transportes si toda la música que está dentro de
las variables se encuentra en un tono coherente.

Asimismo, haga los transportes exclusivamente hacia o desde Do
mayor.  Esto significa que aparte de ésta, las únicas tonalidades
que usaremos serán los tonos de afinación de los instrumentos
transpositores: bes para una trompeta en Si bemol, aes para un
clarinete en La bemol, etc.

@end itemize



@node Large projects
@section Proyectos grandes

Al trabajar en proyectos grandes se hace esencial tener una
estructura clara en los archivos de LilyPond:

@itemize

@item @strong{Utilice un identificador para cada voz},
con un mínimo de estructura dentro de la definición.  La
estructura de la sección @code{\score} es la que cambiará con
mayor probabilidad; por contra, es extremadamente improbable que
cambie la definición de @code{violin} en versiones nuevas de
LilyPond.

@example
violin = \relative @{
g'4 c'8. e16
@}
@dots{}
\score @{
  \new GrandStaff @{
    \new Staff @{
      \violin
    @}
  @}
@}
@end example

@item @strong{Separe los trucos de las definiciones musicales}.  Ya se
mencionó con anterioridad, pero para proyectos grandes es vital.
Quizá tengamos que cambiar la definición de @code{fluegop}, pero
en ese caso sólo lo tendremos que hacer una vez, y aún podremos
evitar tocar nada dentro de @code{violin}.

@example
fluegop = _\markup@{
  \dynamic f \italic \small @{ 2nd @} \hspace #0.1 \dynamic p @}
violin = \relative @{
g'4\fluegop c'8. e16
@}
@end example

@end itemize


@node Troubleshooting
@section Solución de problemas

Antes o después escribirá un archivo que LilyPond no podrá
compilar.  Los mensajes que LilyPond proporciona pueden ayudarle a
encontrar el error, pero en muchos casos tendrá que llevar a cabo
algún tipo de investigación para determinar el origen del
problema.

Las herramientas más poderosas para este cometido son el
comentario de una sola línea (indicado por @code{%}) y el
comentario de bloque (indicado por @code{%@{@dots{}%@}}).  Si no
sabe dónde está el problema, comience convirtiendo grandes
secciones del archivo de entrada en un comentario.  Después de
eliminar una sección convirtiéndola en un comentario, pruebe a
compilar el archivo otra vez.  Si funciona, entonces el problema
debía estar en la porción que había eliminado.  Si no funciona,
continúe eliminando material (transformándolo en comentarios)
hasta que tenga algo que funcione.

En un caso extremo podría terminar con sólo

@example
\score @{
  <<
    % \melodia
    % \armonia
    % \bajo
  >>
  \layout@{@}
@}
@end example

@noindent
(en otras palabras: un archivo sin música)

Si ocurre esto, no abandone.  Descomente un trozo pequeño --
digamos la parte del bajo -- y observe si funciona.  Si no es así,
transforme en comentarios toda la música del bajo (pero deje el
@code{\bajo} de la sección @code{\score} no comentado.

@example
bajo = \relative @{
%@{
  c'4 c c c
  d d d d
%@}
@}
@end example

Ahora empiece poco a poco descomentando cada vez más fracciones de
la parte del @code{bajo} hasta que encuentre la línea del
problema.

Otra técnica de depuración muy útil es la construcción de
@rwebnamed{Tiny examples, Ejemplos mínimos}.


@node Make and Makefiles
@section Make y los Makefiles

@cindex make, archivos de
@cindex make

Posiblemente todas las plataformas en que puede correr LilyPond,
contemplan una posibilidad de software llamada @code{make}. Este
programa lee un archivo especial llamado @code{Makefile} que
define las relaciones de dependencia entre los archivos y qué
instrucciones necesitamos dar al sistema operativo para producir
un archivo a partir de otro.  Por ejemplo, el archivo de make
detallaría cómo obtener @file{balada.pdf} y @file{balada.midi} a
partir de @file{balada.ly} mediante la ejecución de LilyPond.

Existen ocasiones en las que es buena idea crear un
@code{Makefile} para nuestro proyecto, bien sea por nuestra propia
comodidad o como cortesía para otros que posiblemente tengan
acceso a nuestros archivos fuente.  Esto es cierto para proyectos
muy grandes con muchos archivos de inclusión y distintas opciones
de salida (p.ej. partitura completa, particellas, partitura del
director, reducción para piano, etc.), o para proyectos que
requieren instrucciones difíciles para montarlas (como los
proyectos de @code{lilypond-book}). La complejidad y flexibilidad
de los Makefiles varía enormemente según las necesidades y la
habilidad de los autores.  El programa GNU Make viene instalado en
las distribuciones de GNU/Linux y en macOS, y también existe
para Windows.

Consulte el @strong{Manual de GNU Make} para ver todos los
detalles sobre el uso de @code{make}, pues lo que sigue a
continuación ofrece solamente una pincelada de todo lo que es
capaz de hacer.

Las instrucciones que definen las reglas en un archivo de make
difieren en función de la plataforma; por ejemplo, las distintas
formas de GNU/Linux y macOS usan @code{bash}, mientras que Windows
usa @code{cmd}.  Observeque en macOS, tenemos que configurar el
sistema para que utilice el intérprete de órdenes. A continuación
presentamos algunos makefiles de ejemplo, con versiones tanto para
GNU/@/Linux/@/macOS como para Windows.

El primer ejemplo es para una obra orquestal en cuatro movimientos
con la estructura de directorios siguiente:

@example
Sinfonia/
|-- MIDI/
|-- Makefile
|-- Notas/
|   |-- cello.ily
|   |-- cifras.ily
|   |-- trompa.ily
|   |-- oboe.ily
|   |-- trioCuerdas.ily
|   |-- viola.ily
|   |-- violinUno.ily
|   `-- violinDos.ily
|-- PDF/
|-- Particellas/
|   |-- sinfonia-cello.ly
|   |-- sinfonia-trompa.ly
|   |-- sinfonia-oboe.ly
|   |-- sinfonia-viola.ly
|   |-- sinfonia-violinUno.ly
|   `-- sinfonia-violinDos.ly
|-- Partituras/
|   |-- sinfonia.ly
|   |-- sinfoniaI.ly
|   |-- sinfoniaII.ly
|   |-- sinfoniaIII.ly
|   `-- sinfoniaIV.ly
`-- sinfoniaDefs.ily
@end example

Los archivos @file{.ly} de los directorios @code{Partituras} y
@code{Particellas} obtienen las notas de archivos @file{.ily} que
están en el directorio @code{Notas}:

@example
%%% principio del archivo "sinfonia-cello.ly"
\include "../definicionesSinf.ily"
\include "../Notas/cello.ily"
@end example

El makefile tendrá los objetivos de @code{partitura} (la pieza
completa en todo su esplendor), @code{movimientos} (partitura
completa de los movimientos individuales) y @code{particellas}
(partes individuales para los atriles). También existe un objetivo
@code{archivo} que produce un tarball de los archivos fuente,
adecuado para compartirlo a través de la web o por correo
electrónico.  A continuación presentamos el makefile para
GNU/Linux o macOS.  Se debe guardar con el nombre exacto
@code{Makefile} el el directorio superior del proyecto:

@warning{Cuando se define un objetivo o una regla de patrón, las
líneas siguientes deben comenzar con tabuladores, no con
espacios.}

@example
# nombre principal de los archivos de salida
nombre := sinfonia
# La instrucción para ejecutar lilypond
LILY_CMD = lilypond -ddelete-intermediate-files \
                    -dno-point-and-click

# Los sufijos utilizados en este Makefile.
.SUFFIXES: .ly .ily .pdf .midi

.DEFAULT_GOAL := score

PDFDIR := PDF
MIDIDIR := MIDI

# Los archivos de entrada y salida se buscan dentro de los
# directorios relacionados en la variable VPATH.  Todos ellos son
# subdirectorios del directorio en curso (dado por la variable de
# GNU make `CURDIR`).
VPATH = \
  $(CURDIR)/Partituras \
  $(CURDIR)/Particellas \
  $(CURDIR)/Notas \
  $(CURDIR)/$(PDFDIR) \
  $(CURDIR)/$(MIDIDIR)

# La regla de patrón para crear archivos PDF y MIDI a partir de un
# archivo de entrada LY.  Los archivos de salida .pdf se colocan
# en el subdirectorio `PDF`, y los archivos .midi van al
# subdirectorio `MIDI`.
%.pdf %.midi: %.ly | $(PDFDIR) $(MIDIDIR)
	$(LILY_CMD) $<            # esta línea comienza con un tab
	mv "$*.pdf" $(PDFDIR)/    # esta línea comienza con un tab
	mv "$*.midi" $(MIDIDIR)/  # esta línea comienza con un tab


$(PDFDIR):
	mkdir $(PDFDIR)

$(MIDIDIR):
	mkdir $(MIDIDIR)

common := symphonyDefs.ily

notas := \
  cello.ily \
  trompa.ily \
  oboe.ily \
  viola.ily \
  violinUno.ily \
  violinDos.ily

# Dependencias de los movimientos.
$(nombre)I.pdf: $(nombre)I.ly $(notas) $(common)
$(nombre)II.pdf: $(nombre)II.ly $(notas) $(common)
$(nombre)III.pdf: $(nombre)III.ly $(notas) $(common)
$(nombre)IV.pdf: $(nombre)IV.ly $(notas) $(common)

# Dependencias de la partitura completa.
$(nombre).pdf: $(nombre).ly $(notas) $(common)

# Dependencias de las particellas.
$(nombre)-cello.pdf: $(nombre)-cello.ly cello.ily $(common)
$(nombre)-trompa.pdf: $(nombre)-trompa.ly trompa.ily $(common)
$(nombre)-oboes.pdf: $(nombre)-oboe.ly oboe.ily $(common)
$(nombre)-viola.pdf: $(nombre)-viola.ly viola.ily $(common)
$(nombre)-violinUno.pdf: $(nombre)-violinUno.ly violinUno.ily $(common)
$(nombre)-violinDos.pdf: $(nombre)-violinDos.ly violinDos.ily $(common)

# Teclee `make partitura` para generer la partitura completa de
# los cuatro movimientos como un archivo único.
.PHONY: partitura
partitura: $(nombre).pdf

# Teclee `make particellas` para generar todas las particellas.
# Teclee `make fulanito.pdf` para generar la particella del
# instrumento `fulanito`.  Ejemplo: `make sinfonia-cello.pdf`.
.PHONY: particellas
particellas: $(nombre)-cello.pdf \
       $(nombre)-violinUno.pdf \
       $(nombre)-violinDos.pdf \
       $(nombre)-viola.pdf \
       $(nombre)-oboe.pdf \
       $(nombre)-trompa.pdf

# Teclee `make movimientos` para generar los archivos de los
# cuatro movimientos de forma separada.
.PHONY: movimientos
movimientos: $(nombre)I.pdf \
           $(nombre)II.pdf \
           $(nombre)III.pdf \
           $(nombre)IV.pdf

all: partitura particellas movimientos

@end example


Existen ciertas complicaciones en la plataforma Windows. Después
de descargar e instalar el programa GNU Make para Windows, debemos
configurar la ruta adecuada en las variables de entorno del
sistema de forma que el shell del DOS pueda encontrar el programa
Make. Para hacerlo, pulse con el botón derecho sobre "Mi PC",
elija @code{Propiedades} y @code{Avanzadas}. Pulse sobre
@code{Variables de entorno}, y luego en la pestaña @code{Variables
del sistema}, seleccione @code{Ruta}, pulse sobre @code{editar} y
añada la ruta al archivo ejecutable de GNU Make, con lo que
quedará algo parecido a lo siguiente:

@example
C:\Archivos de programa\GnuWin32\bin
@end example

El makefile en sí debe modificarse para que maneje distintas
instrucciones del shell y para que pueda tratar con los espacios
que aparecen en el nombre de algunos directorios del sistema
predeterminados. Windows tiene también una extensión
predeterminada distinta para los archivos MIDI.


@example
## VERSIÓN PARA WINDOWS
##
nombre := sinfonia
LILY_CMD := lilypond -ddelete-intermediate-files \
                    -dno-point-and-click

#obtener el nombre 8.3 de CURDIR (rodeo para los espacios en PATH)
workdir := $(shell for /f "tokens=*" %%b in ("$(CURDIR)") \
          do @@echo %%~sb)

.SUFFIXES: .ly .ily .pdf .mid

.DEFAULT_GOAL := score

PDFDIR := PDF
MIDIDIR := MIDI

VPATH := \
  $(workdir)/Partituras \
  $(workdir)/Particellas \
  $(workdir)/Notas \
  $(workdir)/$(PDFDIR) \
  $(workdir)/$(MIDIDIR)

%.pdf %.mid: %.ly | $(PDFDIR) $(MIDIDIR)
        $(LILY_CMD) $<			# esta línea comienza con un tab
        move /Y "$*.pdf"  $(PDFDIR)/	# comienzo con tab
        move /Y "$*.mid" $(MIDIDIR)/	# comienzo con tab

$(PDFDIR):
    mkdir $(PDFDIR)/

$(MIDIDIR):
    mkdir $(MIDIDIR)/

notas := \
  cello.ily \
  cifras.ily \
  trompa.ily \
  oboe.ily \
  trioCuerdas.ily \
  viola.ily \
  violinUno.ily \
  violinDos.ily

common := symphonyDefs.ily

$(nombre)I.pdf: $(nombre)I.ly $(notas) $(common)
$(nombre)II.pdf: $(nombre)II.ly $(notas) $(common)
$(nombre)III.pdf: $(nombre)III.ly $(notas) $(common)
$(nombre)IV.pdf: $(nombre)IV.ly $(notas) $(common)

$(nombre).pdf: $(nombre).ly $(notas) $(common)

$(nombre)-cello.pdf: $(nombre)-cello.ly cello.ily $(common)
$(nombre)-trompa.pdf: $(nombre)-trompa.ly trompa.ily $(common)
$(nombre)-oboes.pdf: $(nombre)-oboes.ly oboe.ily $(common)
$(nombre)-viola.pdf: $(nombre)-viola.ly viola.ily $(common)
$(nombre)-violinUno.pdf: $(nombre)-violinUno.ly violinUno.ily $(common)
$(nombre)-violinDos.pdf: $(nombre)-violinDos.ly violinDos.ily $(common)

.PHONY: partitura
partitura: $(nombre).pdf

.PHONY: particellas
particellas: $(nombre)-cello.pdf \
       $(nombre)-violinUno.pdf \
       $(nombre)-violinDos.pdf \
       $(nombre)-viola.pdf \
       $(nombre)-oboes.pdf \
       $(nombre)-trompa.pdf

.PHONY: movimientos
movimientos: $(nombre)I.pdf \
           $(nombre)II.pdf \
           $(nombre)III.pdf \
           $(nombre)IV.pdf

all: partitura particellas movimientos
@end example


El Makefile siguiente es para un documento de
@command{lilypond-book} hecho en LaTeX.  Este proyecto tiene un
índice, que requiere ejecutar la instrucción @command{latex} dos
veces para actualizar los enlaces.  Todos los archivos de salida
se almacenan en el directorio @code{salida} para los documentos
.pdf y en el directorio @code{salidahtml} para la salida en
formato html.

@example
SHELL=/bin/sh
NOMBRE=miproyecto
DIR_SALIDA=salida
DIR_WEB=salidahtml
VISOR=acroread
NAVEGADOR=firefox
LILYBOOK_PDF=lilypond-book --output=$(DIR_SALIDA) --pdf $(NOMBRE).lytex
LILYBOOK_HTML=lilypond-book --output=$(DIR_WEB) $(NOMBRE).lytex
PDF=cd $(DIR_SALIDA) && pdflatex $(NOMBRE)
HTML=cd $(DIR_WEB) && latex2html $(NOMBRE)
INDICE=cd $(DIR_SALIDA) && makeindex $(NOMBRE)
VISTA_PREVIA=$(VISOR) $(DIR_SALIDA)/$(NOMBRE).pdf &

all: pdf web guardar

pdf:
        $(LILYBOOK_PDF)  # comienza con un tab
        $(PDF)           # comienza con un tab
        $(INDICE)        # comienza con un tab
        $(PDF)           # comienza con un tab
        $(VISTA_PREVIA)  # comienza con un tab

web:
        $(LILYBOOK_HTML) # comienza con un tab
        $(HTML)          # comienza con un tab
        cp -R $(DIR_WEB)/$(NOMBRE)/ ./  # comienza con un tab
        $(NAVEGADOR) $(NOMBRE)/$(NOMBRE).html &  # comienza con un tab

guardar: pdf
        cp $(DIR_SALIDA)/$(NOMBRE).pdf $(NOMBRE).pdf  # comienza con un tab

clean:
        rm -rf $(DIR_SALIDA) # comienza con un tab

web-clean:
        rm -rf $(DIR_WEB) # comienza con un tab

archivo:
        tar -cvvf miproyecto.tar \ # comienza con un tab
        --exclude=salida/* \
        --exclude=salidahtml/* \
        --exclude=miproyecto/* \
        --exclude=*midi \
        --exclude=*pdf \
        --exclude=*~ \
        ../MiProyecto/*
@end example

@c HACER: conseguir que funcione en Windows

El makefile anterior no funciona en Windows.  Una alternativa para
los usuarios de Windows sería crear un archivo de lotes sencillo
que contenga las instrucciones de montaje.  Esto no rastrea las
dependencias en la manera en que lo hace un makefile, pero al
menos reduce el proceso de construcción a una sola instrucción.
Guarde el código siguiente como @command{montaje.bat} o
@command{montaje.cmd}.  El archivo de lotes se puede ejecutar en
la línea de órdenes del DOS o simplemente haciendo doble click
sobre su icono.

@example
lilypond-book --output=salida --pdf miproyecto.lytex
cd salida
pdflatex miproyecto
makeindex miproyecto
pdflatex miproyecto
cd ..
copy salida\miproyecto.pdf MiProyecto.pdf
@end example


@morerefs
Manual de utilización del programa:
@ref{Command-line usage},
@ref{lilypond-book}.
@endmorerefs
