1 @c -*- coding: utf-8; mode: texinfo; documentlanguage: es -*-
4 Translation of GIT committish: 26a079ca2393d053315ef8dbef626c897dc9645a
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 Tutorial de Scheme
14 @appendix Tutorial de Scheme
15 @translationof Scheme tutorial
19 @cindex Scheme, código en línea
20 @cindex acceder a Scheme
21 @cindex evaluar Scheme
24 LilyPond utiliza el lenguaje de programación Scheme, tanto como parte
25 de la sintaxis del código de entrada, como para servir de mecanismo
26 interno que une los módulos del programa entre sí. Esta sección es
27 una panorámica muy breve sobre cómo introducir datos en Scheme. Si
28 quiere saber más sobre Scheme, consulte
29 @uref{http://@/www@/.schemers@/.org}.
31 LilyPond utiliza la implementación GNU Guile de Scheme, que está
32 basada en el estándar @qq{R5RS} del lenguaje. Si está aprendiendo
33 Scheme para usarlo con LilyPond, no se recomienda trabajar con una
34 implementación distinta (o que se refiera a un estándar diferente).
35 Hay información sobre Guile en
36 @uref{http://www.gnu.org/software/guile/}. El estándar de Scheme
37 @qq{R5RS} se encuentra en
38 @uref{http://www.schemers.org/Documents/Standards/R5RS/}.
41 * Introducción a Scheme::
42 * Scheme dentro de LilyPond::
43 * Construir funciones complicadas::
46 @node Introducción a Scheme
47 @section Introducción a Scheme
48 @translationof Introduction to Scheme
50 Comenzaremos con una introducción a Scheme. Para esta breve
51 introducción utilizaremos el intérprete GUILE para explorar la manera
52 en que el lenguaje funciona. Una vez nos hayamos familiarizado con
53 Scheme, mostraremos cómo se puede integrar el lenguaje en los archivos
58 * Cajón de arena de Scheme::
59 * Variables de Scheme::
60 * Tipos de datos simples de Scheme::
61 * Tipos de datos compuestos de Scheme::
62 * Cálculos en Scheme::
63 * Procedimientos de Scheme::
64 * Condicionales de Scheme::
67 @node Cajón de arena de Scheme
68 @subsection Cajón de arena de Scheme
69 @translationof Scheme sandbox
71 La instalación de LilyPond incluye también la de la implementación
72 Guile de Scheme. Sobre casi todos los sistemas puede experimentar en
73 una @qq{caja de arena} de Scheme abriendo una ventana del terminal y
74 tecleando @q{guile}. En algunos sistemas, sobre todo en Windows,
75 podría necesitar ajustar la variable de entorno @code{GUILE_LOAD_PATH}
76 a la carpeta @code{../usr/share/guile/1.8} dentro de la instalación de
77 LilyPond (para conocer la ruta completa a esta carpeta, consulte
78 @rlearning{Otras fuentes de información}). Como alternativa, los
79 usuarios de Windows pueden seleccionar simplemente @q{Ejecutar} del
80 menú Inicio e introducir @q{guile}.
82 Sin embargo, está disponible un cajón de arena de Scheme listo para
83 funcionar con todo LilyPond cargado, con esta instrucción de la línea
86 lilypond scheme-sandbox
90 Una vez está funcionando el cajón de arena, verá un indicador
97 Podemos introducir expresiones de Scheme en este indicador para
98 experimentar con Scheme. Si quiere usar la biblioteca readline de GNU
99 para una más cómoda edición de la línea de órdenes de Scheme, consulte
100 el archivo @file{ly/scheme-sandbox.ly} para más información. Si ya ha
101 activado la biblioteca readline para las sesiones de Guile
102 interactivas fuera de LilyPond, debería funcionar también en el cajón
105 @node Variables de Scheme
106 @subsection Variables de Scheme
107 @translationof Scheme variables
109 Las variables de Scheme pueden tener cualquier valor válido de Scheme,
110 incluso un procedimiento de Scheme.
112 Las variables de Scheme se crean con @code{define}:
119 Las variables de Scheme se pueden evaluar en el indicador del sistema
120 de guile, simplemente tecleando el nombre de la variable:
128 Las variables de Scheme se pueden imprimir en la pantalla utilizando
137 Observe que el valor @code{2} y el indicador del sistema @code{guile}
138 se muestran en la misma línea. Esto se puede evitar llamando al
139 procedimiento de nueva línea o imprimiendo un carácter de nueva línea.
142 guile> (display a)(newline)
144 guile> (display a)(display "\n")
149 Una vez que se ha creado una variable, su valor se puede modificar con
153 guile> (set! a 12345)
159 @node Tipos de datos simples de Scheme
160 @subsection Tipos de datos simples de Scheme
161 @translationof Scheme simple data types
163 El concepto más básico de un lenguaje son sus tipos de datos: números,
164 cadenas de caracteres, listas, etc. He aquí una lista de los tipos de
165 datos que son de relevancia respecto de la entrada de LilyPond.
169 Los valores Booleanos son Verdadero y Falso. Verdadero en Scheme es
170 @code{#t} y Falso es @code{#f}.
175 Los números se escriben de la forma normal, @code{1} es el número
176 (entero) uno, mientras que @w{@code{-1.5}} es un número en coma flotante
177 (un número no entero).
180 Las cadenas se encierran entre comillas:
186 Las cadenas pueden abarcar varias líneas:
195 y los caracteres de nueva línea al final de cada línea se incluirán
198 Los caracteres de nueva línea también se pueden añadir mediante la
199 inclusión de @code{\n} en la cadena.
202 "esto\nes una\ncadena de varias líneas"
206 Las comillas dobles y barras invertidas se añaden a las cadenas
207 precediéndolas de una barra invertida. La cadena @code{\a dijo "b"}
216 Existen más tipos de datos de Scheme que no se estudian aquí. Para
217 ver un listado completo, consulte la guía de referencia de Guile,
218 @uref{http://www.gnu.org/software/guile/manual/html_node/Simple-Data-Types.html}.
220 @node Tipos de datos compuestos de Scheme
221 @subsection Tipos de datos compuestos de Scheme
222 @translationof Scheme compound data types
224 También existen tipos de datos compuestos en Scheme. Entre los tipos
225 más usados en la programación de LilyPond se encuentran las parejas,
226 las listas, las listas-A y las tablas de hash.
230 El tipo fundacional de datos compuestos de Scheme es la @code{pareja}.
231 Como se espera por su nombre, una pareja son dos valores unidos en uno
232 solo. El operador que se usa para formar una pareja se llama
241 Observe que la pareja se imprime como dos elementos rodeados por
242 paréntesis y separados por un espacio, un punto (@code{.}) y otro
243 espacio. El punto @emph{no es} un punto decimal, sino más bien un
246 Las parejas también se pueden introducir como valores literales
247 precediéndolos de un carácter de comilla simple o apóstrofo.
255 Los dos elementos de una pareja pueden ser cualquier valor válido de
261 guile> '("bla-bla" . 3.1415926535)
262 ("bla-bla" . 3.1415926535)
266 Se puede accede al primero y segundo elementos de la pareja mediante
267 los procedimientos de Scheme @code{car} y @code{cdr}, respectivamente.
270 guile> (define mipareja (cons 123 "Hola")
272 guile> (car mipareja)
274 guile> (cdr mipareja)
281 Nota: @code{cdr} se pronuncia "could-er", según Sussman y Abelson,
283 @uref{http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html#footnote_Temp_133}
288 Una estructura de datos muy común en Scheme es la @emph{lista}.
289 Formalmente, una lista se define como la lista vacía (representada
290 como @code{'()}, o bien como una pareja cuyo @code{cdr} es una lista.
292 Existen muchas formas de crear listas. Quizá la más común es con el
293 procedimiento @code{list}:
296 guile> (list 1 2 3 "abc" 17.5)
300 Como se ve, una lista se imprime en la forma de elementos individuales
301 separados por espacios y encerradas entre paréntesis. A diferencia de
302 las parejas, no hay ningún punto entre los elementos.
304 También se puede escribir una lista como una lista literal encerrando
305 sus elementos entre paréntesis y añadiendo un apóstrofo:
308 guile> '(17 23 "fulano" "mengano" "zutano")
309 (17 23 "fulano" "mengano" "zutano")
312 Las listas son una parte fundamental de Scheme. De hecho, Scheme se
313 considera un dialecto de Lisp, donde @q{lisp} es una abreviatura de
314 @q{List Processing} (proceso de listas). Todas las expresiones de
317 @subheading Listas asociativas (listas-A)
319 Un tipo especial de listas son las @emph{listas asociativas} o
320 @emph{listas-A}. Se puede usar una lista-A para almacenar datos para
321 su fácil recuperación posterior.
323 Las listas-A son listas cuyos elementos son parejas. El @code{car} de
324 cada elemento se llama @emph{clave}, y el @code{cdr} de cada elemento
325 se llama @emph{valor}. El procedimiento de Scheme @code{assoc} se usa
326 para recuperar un elemento de la lista-A, y @code{cdr} se usa para
330 guile> (define mi-lista-a '((1 . "A") (2 . "B") (3 . "C")))
332 ((1 . "A") (2 . "B") (3 . "C"))
333 guile> (assoc 2 mi-lista-a)
335 guile> (cdr (assoc 2 mi-lista-a))
340 Las listas-A se usan mucho en LilyPond para almacenar propiedades y
343 @subheading Tablas de hash
345 Estructuras de datos que se utilizan en LilyPond de forma ocasional.
346 Una tabla de hash es similar a una matriz, pero los índices de la
347 matriz pueden ser cualquier tipo de valor de Scheme, no sólo enteros.
349 Las tablas de hash son más eficientes que las listas-A si hay una gran
350 cantidad de datos que almacenar y los datos cambian con muy poca
353 La sintaxis para crear tablas de hash es un poco compleja, pero
354 veremos ejemplos de ello en el código fuente de LilyPond.
357 guile> (define h (make-hash-table 10))
360 guile> (hashq-set! h 'key1 "val1")
362 guile> (hashq-set! h 'key2 "val2")
364 guile> (hashq-set! h 3 "val3")
368 Los valores se recuperan de las tablas de hash mediante
372 guile> (hashq-ref h 3)
374 guile> (hashq-ref h 'key2)
379 Las claves y los valores se recuperan como una pareja con
380 @code{hashq-get-handle}. Ésta es la forma preferida, porque devuelve
381 @code{#f} si no se encuentra la clave.
384 guile> (hashq-get-handle h 'key1)
386 guile> (hashq-get-handle h 'frob)
391 @node Cálculos en Scheme
392 @subsection Cálculos en Scheme
393 @translationof Calculations in Scheme
396 Todo el tiempo hemos estado usando listas. Un cálculo, como @code{(+
397 1 2)} también es una lista (que contiene el símbolo @code{+} y los
398 números 1 y@tie{}2). Normalmente, las listas se interpretan como
399 cálculos, y el intérprete de Scheme sustituye el resultado del
400 cálculo. Para escribir una lista, detenemos la evaluación. Esto se
401 hace precediendo la lista por un apóstrofo @code{'}. Así, para los
402 cálculos no usamos ningún apóstrofo.
404 Dentro de una lista o pareja precedida de apóstrofo, no hay necesidad
405 de escribir ningún apóstrofo más. Lo siguiente es una pareja de
406 símbolos, una lista de símbolos y una lista de listas respectivamente:
410 #'(staff clef key-signature)
415 Scheme se puede usar para hacer cálculos. Utiliza sintaxis
416 @emph{prefija}. Sumar 1 y@tie{}2 se escribe como @code{(+ 1 2)} y no
417 como el tradicional @math{1+2}.
424 Los cálculos se pueden anidar; el resultado de una función se puede
425 usar para otro cálculo.
432 Estos cálculos son ejemplos de evaluaciones; una expresión como
433 @code{(* 3 4)} se sustituye por su valor @code{12}.
435 Los cálculos de Scheme son sensibles a las diferencias entre enteros y
436 no enteros. Los cálculos enteros son exactos, mientras que los no
437 enteros se calculan con los límites de precisión adecuados:
446 Cuando el intérprete de Scheme encuentra una expresión que es una
447 lista, el primer elemento de la lista se trata como un procedimiento a
448 evaluar con los argumentos del resto de la lista. Por tanto, todos
449 los operadores en Scheme son operadores prefijos.
451 Si el primer elemento de una expresión de Scheme que es una lista que
452 se pasa al intérprete @emph{no es} un operador o un procedimiento, se
462 <unnamed port>:52:1: In expression (1 2 3):
463 <unnamed port>:52:1: Wrong type to apply: 1
468 Aquí podemos ver que el intérprete estaba intentando tratar el 1 como
469 un operador o procedimiento, y no pudo hacerlo. De aquí que el error
470 sea "Wrong type to apply: 1".
472 Así pues, para crear una lista debemos usar el operador de lista, o
473 podemos precederla de un apóstrofo para que el intérprete no trate de
484 Esto es un error que puede aparecer cuando trabaje con Scheme dentro
488 La misma asignación se puede hacer también completamente en Scheme,
491 #(define veintiCuatro (* 2 doce))
494 @c this next section is confusing -- need to rewrite
496 El @emph{nombre} de una variable también es una expresión, similar a
497 un número o una cadena. Se introduce como
504 @cindex comillas en Scheme
506 El apóstrofo @code{'} evita que el intérprete de Scheme sustituya
507 @code{veintiCuatro} por @code{24}. En vez de esto, obtenemos el
508 nombre @code{veintiCuatro}.
512 @node Procedimientos de Scheme
513 @subsection Procedimientos de Scheme
514 @translationof Scheme procedures
516 Los procedimientos de Scheme son expresiones de Scheme ejecutables que
517 devuelven un valor resultante de su ejecución. También pueden
518 manipular variables definidas fuera del procedimiento.
520 @subheading Definir procedimientos
522 Los procedimientos se definen en Scheme con @code{define}:
525 (define (nombre-de-la-función arg1 arg2 ... argn)
526 expresión-de-scheme-que-devuelve-un-valor)
529 Por ejemplo, podemos definir un procedimiento para calcular la media:
532 guile> (define (media x y) (/ (+ x y) 2))
534 #<procedure media (x y)>
537 Una vez se ha definido un procedimiento, se llama poniendo el nombre
538 del procedimiento dentro de una lista. Por ejemplo, podemos calcular
546 @subheading Predicados
548 Los procedimientos de Scheme que devuelven valores booleanos se suelen
549 llamar @emph{predicados}. Por convenio (pero no por necesidad),
550 los nombres de predicados acaban en un signo de interrogación:
553 guile> (define (menor-que-diez? x) (< x 10))
554 guile> (menor-que-diez? 9)
556 guile> (menor-que-diez? 15)
560 @subheading Valores de retorno
562 Los procedimientos de Scheme siempre devuelven un valor de retorno,
563 que es el valor de la última expresión ejecutada en el procedimiento.
564 El valor de retorno puede ser cualquier valor de Scheme válido,
565 incluso una estructura de datos compleja o un procedimiento.
567 A veces, el usuario quiere tener varias expresiones de Scheme dentro
568 de un procedimiento. Existen dos formas en que se pueden combinar
569 distintas expresiones. La primera es el procedimiento @code{begin},
570 que permite evaluar varias expresiones, y devuelve el valor de la
574 guile> (begin (+ 1 2) (- 5 8) (* 2 2))
578 La segunda forma de combinar varias expresiones es dentro de un bloque
579 @code{let}. Dentro de un bloque let, se crean una serie de ligaduras
580 o asignaciones, y después se evalúa una secuencia de expresiones que
581 pueden incluir esas ligaduras o asignaciones. El valor de retorno del
582 bloque let es el valor de retorno de la última sentencia del bloque
586 guile> (let ((x 2) (y 3) (z 4)) (display (+ x y)) (display (- z 4))
587 ... (+ (* x y) (/ z x)))
591 @node Condicionales de Scheme
592 @subsection Condicionales de Scheme
593 @translationof Scheme conditionals
597 Scheme tiene un procedimiento @code{if}:
600 (if expresión-de-prueba expresión-de-cierto expresión-de-falso)
603 @var{expresión-de-prueba} es una expresión que devuelve un valor
604 booleano. Si @var{expresión-de-prueba} devuelve @code{#t}, el
605 procedimiento @code{if} devuelve el valor de la
606 @var{expresión-de-cierto}, en caso contrario devuelve el valor de la
607 @var{expresión-de-falso}.
612 guile> (if (> a b) "a es mayor que b" "a no es mayor que b")
613 "a no es mayor que b"
618 Otro procedimiento condicional en scheme es @code{cond}:
621 (cond (expresión-de-prueba-1 secuencia-de-expresiones-resultante-1)
622 (expresión-de-prueba-2 secuencia-de-expresiones-resultante-2)
624 (expresión-de-prueba-n secuencia-de-expresiones-resultante-n))
632 guile> (cond ((< a b) "a es menor que b")
633 ... ((= a b) "a es igual a b")
634 ... ((> a b) "a es mayor que b"))
638 @node Scheme dentro de LilyPond
639 @section Scheme dentro de LilyPond
640 @translationof Scheme in LilyPond
643 * Sintaxis del Scheme de LilyPond::
644 * Variables de LilyPond::
645 * Variables de entrada y Scheme::
646 * Importación de Scheme dentro de LilyPond::
647 * Propiedades de los objetos::
648 * Variables de LilyPond compuestas::
649 * Representación interna de la música::
652 @node Sintaxis del Scheme de LilyPond
653 @subsection Sintaxis del Scheme de LilyPond
654 @translationof LilyPond Scheme syntax
658 El intérprete Guile forma parte de LilyPond, lo que significa que se
659 puede incluir Scheme dentro de los archivos de entrada de LilyPond.
660 Existen varios métodos para incluir Scheme dentro de LilyPond.
662 La manera más sencilla es utilizar el símbolo de
663 almohadilla@tie{}@code{#} antes de una expresión de Scheme.
665 Ahora bien, el código de entrada de LilyPond se estructura en
666 elementos y expresiones, de forma parecida a cómo el lenguaje humano
667 se estructura en palabras y frases. LilyPond tiene un analizador
668 léxico que reconoce elementos indivisibles (números literales, cadenas
669 de texto, elementos de Scheme, nombres de nota, etc.), y un analizador
670 sintáctico que entiende la sintaxis, la @ruser{Gramática de LilyPond}.
671 Una vez que sabe que se aplica una regla sintáctica concreta, ejecuta
672 las acciones asociadas con ella.
674 El método del símbolo de almohadilla@tie{}@code{#} para incrustar
675 Scheme se adapta de forma natural a este sistema. Una vez que el
676 analizador léxico ve un símbolo de almohadilla, llama al lector de
677 Scheme para que lea una expresión de Scheme completa (que puede ser un
678 identificador, una expresión encerrada entre paréntesis, o algunas
679 otras cosas). Después de que se ha leído la expresión de Scheme, se
680 almacena como el valor de un elemento @code{SCM_TOKEN} de la
681 gramática. Después de que el analizador sintáctico ya sabe cómo hacer
682 uso de este elemento, llama a Guila para que evalúe la expresión de
683 Scheme. Dado que el analizador sintáctico suele requerir un poco de
684 lectura por delante por parte del analizador léxico para tomar sus
685 decisiones de análisis sintáctico, esta separación de lectura y
686 evaluación entre los analizadores léxico y sintáctico es justamente lo
687 que se necesita para mantener sincronizadas las ejecuciones de
688 expresiones de LilyPond y de Scheme. Por este motivo se debe usar el
689 símbolo de almohadilla@tie{}@code{#} para llamar a Scheme siempre que
692 Otra forma de llamar al intérprete de Scheme desde lilyPond es el uso
693 del símbolo de dólar@tie{}@code{$} en lugar de la almohadilla para
694 introducir las expresiondes de Scheme. En este caso, LilyPond evalúa
695 el código justo después de que el analizador léxico lo ha leído.
696 Comprueba el tipo resultante de la expresión de Scheme y después
697 selecciona un tipo de elemento (uno de los varios elementos
698 @code{xxx_IDENTIFIER} dentro de la sintaxis) para él. Crea una
699 @emph{copia} del valor y la usa como valor del elemento. Si el valor
700 de la expresión es vacío (El valor de Guile de @code{*unspecified*}),
701 no se pasa nada en absoluto al analizador sintáctico.
703 Éste es, de hecho, el mismo mecanismo exactamente que LilyPond emplea
704 cuando llamamos a cualquier variable o función musical por su nombre,
705 como @code{\nombre}, con la única diferencia de que el nombre viene
706 determinado por el analizador léxico de LilyPond sin consultar al
707 lector de Scheme, y así solamente se aceptan los nombres de variable
708 consistentes con el modo actual de LilyPond.
710 La acción inmediata de @code{$} puede llevar a alguna que otra
711 sorpresa, véase @ref{Variables de entrada y Scheme}. La utilización
712 de @code{#} donde el analizador sintáctico lo contempla es normalmente
713 preferible. Dentro de las expresiones musicales, aquellas que se
714 crean utilizando @code{#} @emph{se interprentan} como música. Sin
715 embargo, @emph{no se copian} antes de ser utilizadas. Si forman parte
716 de alguna estructura que aún podría tener algún uso, quizá tenga que
717 utilizar explícitamente @code{ly:music-deep-copy}.
721 También existen los operadores de @q{división de listas} @code{$@@} y
722 @code{#@@} que insertan todos los elementos de una lista dentro del
723 contexto circundante.
725 Ahora echemos un vistazo a algo de código de Scheme real. Los
726 procedimientos de Scheme se pueden definir dentro de los archivos de
730 #(define (media a b c) (/ (+ a b c) 3))
733 Observe que los comentarios de LilyPond (@code{%} y @code{%@{ %@}}) no
734 se pueden utilizar dentro del código de Scheme, ni siquiera dentro de
735 un archivo de entrada de LilyPond, porque es el intérprete Guile, y no
736 el analizador léxico de LilyPond, el que está leyendo la expresión de
737 Scheme. Los comentarios en el Scheme de Guile se introducen como
741 ; esto es un comentario de una línea
744 Esto es un comentario de bloque (no anidable) estilo Guile
745 Pero se usan rara vez por parte de los Schemers y nunca dentro del
746 código fuente de LilyPond
750 Durante el resto de esta sección, supondremos que los datos se
751 introducen en un archivo de música, por lo que añadiremos
752 almohadillas@tie{}@code{#} al principio de todas las expresiones de Scheme.
754 Todas las expresiones de Scheme del nivel jerárquico superior dentro
755 de un archivo de entrada de LilyPond se pueden combinar en una sola
756 expresión de Scheme mediante la utilización del operador @code{begin}:
761 (define menganito 1))
765 @node Variables de LilyPond
766 @subsection Variables de LilyPond
767 @translationof LilyPond variables
769 Las variables de LilyPond se almacenan internamente en la forma de
770 variables de Scheme. Así,
783 Esto significa que las variables de LilyPond están disponibles para su
784 uso dentro de expresiones de Scheme. Por ejemplo, podríamos usar
787 veintiCuatro = (* 2 doce)
791 lo que daría lugar a que el número 24 se almacenase dentro de la
792 variable @code{veintiCuatro} de LilyPond (y de Scheme).
794 La forma usual de referirse a las variables de LilyPond,
795 @ref{Sintaxis del Scheme de LilyPond},
797 es llamarlas usando una barra invertida, es decir
798 @code{\veintiCuatro}. Dado que esto crea una copia para la mayor
799 parte de los tipos internos de LilyPond, concretamente las expresiones
800 musicales, las funciones musicales no sueln crear copias del material
801 que ellas mismas modifican. Por este motivo, las expresiones
802 musicales dadas con @code{#} no deberían, por lo general, contener
803 material que no se haya creado partiendo de cero o copiado
804 explícitamente en lugar de estar referenciado directamente.
806 @node Variables de entrada y Scheme
807 @subsection Variables de entrada y Scheme
808 @translationof Input variables and Scheme
810 El formato de entrada contempla la noción de variables: en el
811 siguiente ejemplo, se asigna una expresión musical a una variable con
812 el nombre @code{traLaLa}.
815 traLaLa = @{ c'4 d'4 @}
820 También hay una forma de ámbito: en el ejemplo siguiente, el bloque
821 @code{\layout} también contiene una variable @code{traLaLa}, que es
822 independiente de la @code{\traLaLa} externa.
825 traLaLa = @{ c'4 d'4 @}
826 \layout @{ traLaLa = 1.0 @}
830 En efecto, cada archivo de entrada constituye un ámbito, y cada bloque
831 @code{\header}, @code{\midi} y @code{\layout} son ámbitos anidados
832 dentro del ámbito de nivel superior.
834 Tanto las variables como los ámbitos están implementados en el sistema
835 de módulos de GUILE. A cada ámbito se adjunta un módulo anónimo de
836 Scheme. Una asignación de la forma:
839 traLaLa = @{ c'4 d'4 @}
843 se convierte internamente en una definición de Scheme:
846 (define traLaLa @var{Valor Scheme de `@code{... }'})
849 Esto significa que las variables de LilyPond y las variables de Scheme
850 se pueden mezclar con libertad. En el ejemplo siguiente, se almacena
851 un fragmento de música en la variable @code{traLaLa}, y se duplica
852 usando Scheme. El resultado se importa dentro de un bloque
853 @code{\score} por medio de una segunda variable @code{twice}:
856 traLaLa = { c'4 d'4 }
858 #(define newLa (map ly:music-deep-copy
859 (list traLaLa traLaLa)))
861 (make-sequential-music newLa))
866 @c Due to parser lookahead
868 En realidad, éste es un ejemplo bastante interesante. La asignación
869 solo tiene lugar después de que el analizador sintáctico se ha
870 asegurado de que no sigue nada parecido a @code{\addlyrics}, de manera
871 que necesita comprobar lo que viene a continuación. Lee el símbolo
872 @code{#} y la expresión de Scheme siguiente @emph{sin} evaluarla, de
873 forma que puede proceder a la asignación, y @emph{posteriormente}
874 ejecutar el código de Scheme sin problema.
876 @node Importación de Scheme dentro de LilyPond
877 @subsection Importación de Scheme dentro de LilyPond
878 @translationof Importing Scheme in LilyPond
882 El ejemplo anterior muestra cómo @q{exportar} expresiones musicales
883 desde la entrada al intérprete de Scheme. Lo contrario también es
884 posible. Colocándolo después de @code{$}, un valor de Scheme se
885 interpreta como si hubiera sido introducido en la sintaxis de
886 LilyPond. En lugar de definir @code{\twice}, el ejemplo anterior
887 podría también haberse escrito como
891 $(make-sequential-music newLa)
894 Podemos utilizar @code{$} con una expresión de Scheme en cualquier
895 lugar en el que usaríamos @code{\@var{nombre}} después de haber
896 asignado la expresión de Scheme a una variable @var{nombre}. Esta
897 sustitución se produce dentro del @q{analizador léxico}, de manera que
898 LilyPond no llega a darse cuenta de la diferencia.
900 Sin embargo, existe un inconveniente, el de la medida del tiempo. Si
901 hubiésemos estado usando @code{$} en vez de @code{#} para definir
902 @code{newLa} en el ejemplo anterior, la siguiente definición de Scheme
903 habría fracasado porque @code{traLaLa} no habría sido definida aún.
904 Para ver una explicación de este problema de momento temporal, véase
905 @ref{Sintaxis del Scheme de LilyPond}.
909 Un conveniente aspecto posterior pueden ser los operadores de
910 @q{división de listas} @code{$@@} y @code{#@@} para la inserción de
911 los elementos de una lista dentro del contexto circundante.
912 Utilizándolos, la última parte del ejemplo se podría haber escrito
920 Aquí, cada elemento de la lista que está almacenado en @code{newLa} se
921 toma en secuencia y se inserta en la lista, como si hubiésemos escrito
924 @{ #(first newLa) #(second newLa) @}
927 Ahora bien, en todas esas formas, el código de Scheme se evalúa en el
928 momento en que el código de entrada aún se está procesando, ya sea en
929 el analizador léxico o en el analizador sintáctico. Si necesitamos
930 que se ejecute en un momento posterior, debemos consultar
931 @ref{Funciones de Scheme vacías}, o almacenarlo dentro de un
936 (ly:set-option 'point-and-click #f))
945 No es posible mezclar variables de Scheme y de LilyPond con la opción
949 @node Propiedades de los objetos
950 @subsection Propiedades de los objetos
951 @translationof Object properties
953 Las propiedades de los objetos se almacenan en LilyPond en forma de
954 cadenas de listas-A, que son listas de listas-A. Las propiedades se
955 establecen añadiendo valores al principio de la lista de propiedades.
956 Las propiedades se leen extrayendo valores de las listas-A.
958 El establecimiento de un valor nuevo para una propiedad requiere la
959 asignación de un valor a la lista-A con una clave y un valor. La
960 sintaxis de LilyPond para hacer esto es la siguiente:
963 \override Stem.thickness = #2.6
966 Esta instrucción ajusta el aspecto de las plicas. Se añade una
967 entrada de lista-A @code{'(thickness . 2.6)} a la lista de propiedades
968 de un objeto @code{Stem}. @code{thickness} se mide a partir del
969 grosor de las líneas del pentagrama, y así estas plicas serán
970 @code{2.6} veces el grosor de las líneas del pentagrama. Esto hace
971 que las plicas sean casi el doble de gruesas de lo normal. Para
972 distinguir entre las variables que se definen en los archivos de
973 entrada (como @code{veintiCuatro} en el ejemplo anterior) y las
974 variables de los objetos internos, llamaremos a las últimas
975 @q{propiedades} y a las primeras @q{variables.} Así, el objeto plica
976 tiene una propiedad @code{thickness} (grosor), mientras que
977 @code{veintiCuatro} es una variable.
979 @cindex propiedades frente a variables
980 @cindex variables frente a propiedades
982 @c todo -- here we're getting interesting. We're now introducing
983 @c LilyPond variable types. I think this deserves a section all
986 @node Variables de LilyPond compuestas
987 @subsection Variables de LilyPond compuestas
988 @translationof LilyPond compound variables
990 @subheading Desplazamientos
992 Los desplazamientos bidimensionales (coordenadas X e Y) se almacenan
993 como @emph{parejas}. El @code{car} del desplazamiento es la
994 coordenada X, y el @code{cdr} es la coordenada Y.
997 \override TextScript.extra-offset = #'(1 . 2)
1000 Esto asigna la pareja @code{(1 . 2)} a la propiedad
1001 @code{extra-offset} del objeto TextScript. Estos números se miden en
1002 espacios de pentagrama, y así esta instrucción mueve el objeto un
1003 espacio de pentagrama a la derecha, y dos espacios hacia arriba.
1005 Los procedimientos para trabajar con desplazamientos están en
1006 @file{scm/lily-library.scm}.
1008 @subheading Fractions
1010 Fractions as used by LilyPond are again stored as @emph{pairs}, this
1011 time of unsigned integers. While Scheme can represent rational numbers
1012 as a native type, musically @samp{2/4} and @samp{1/2} are not the same,
1013 and we need to be able to distinguish between them. Similarly there are
1014 no negative @q{fractions} in LilyPond's mind. So @code{2/4} in LilyPond
1015 means @code{(2 . 4)} in Scheme, and @code{#2/4} in LilyPond means
1016 @code{1/2} in Scheme.
1018 @subheading Dimensiones
1020 Las parejas se usan también para almacenar intervalos, que representan
1021 un rango de números desde el mínimo (el @code{car}) hasta el máximo
1022 (el @code{cdr}). Los intervalos se usan para almacenar las
1023 dimensiones en X y en Y de los objetos imprimibles. Para dimensiones
1024 en X, el @code{car} es la coordenada X de la parte izquierda, y el
1025 @code{cdr} es la coordenada X de la parte derecha. Para las
1026 dimensiones en Y, el @code{car} es la coordenada inferior, y el
1027 @code{cdr} es la coordenada superior.
1029 Los procedimientos para trabajar con intervalos están en
1030 @file{scm/lily-library.scm}. Se deben usar estos procedimientos
1031 siempre que sea posible, para asegurar la consistencia del código.
1033 @subheading Listas-A de propiedades
1035 Una lista-A de propiedades es una estructura de datos de LilyPond que
1036 es una lista-A cuyas claves son propiedades y cuyos valores son
1037 expresiones de Scheme que dan el valor deseado de la propiedad.
1039 Las propiedades de LilyPond son símbolos de Scheme, como por ejemplo
1042 @subheading Cadenas de listas-A
1044 Una cadena de listas-A es una lista que contiene listas-A de
1047 El conjunto de todas las propiedades que se aplican a un grob se
1048 almacena por lo general como una cadena de listas-A. Para poder
1049 encontrar el valor de una propiedad determinada que debería tener un
1050 grob, se busca por todas las listas-A de la cadena, una a una,
1051 tratando de encontrar una entrada que contenga la clave de la
1052 propiedad. Se devuelve la primera entrada de lista-A que se
1053 encuentre, y el valor es el valor de la propiedad.
1055 El procedimiento de Scheme @code{chain-assoc-get} se usa normalmente
1056 para obtener los valores de propiedades.
1058 @node Representación interna de la música
1059 @subsection Representación interna de la música
1060 @translationof Internal music representation
1062 Internamente, la música se representa como una lista de Scheme. La
1063 lista contiene varios elementos que afectan a la salida impresa. El
1064 análisis sintáctico es el proceso de convertir la música de la
1065 representación de entrada de LilyPond a la representación interna de
1068 Cuando se analiza una expresión musical, se convierte en un conjunto
1069 de objetos musicales de Scheme. La propiedad definitoria de un objeto
1070 musical es que ocupa un tiempo. El tiempo que ocupa se llama
1071 @emph{duración}. Las duraciones se expresan como un número racional
1072 que mide la longitud del objeto musical en redondas.
1074 Un objeto musical tiene tres clases de tipos:
1077 nombre musical: Cada expresión musical tiene un nombre. Por ejemplo,
1078 una nota lleva a un @rinternals{NoteEvent}, y @code{\simultaneous}
1079 lleva a una @rinternals{SimultaneousMusic}. Hay una lista de todas
1080 las expresiones disponibles en el manual de Referencia de
1081 funcionamiento interno, bajo el epígrafe @rinternals{Music
1085 @q{type} (tipo) o interface: Cada nombre musical tiene varios
1086 @q{tipos} o interfaces, por ejemplo, una nota es un @code{event}, pero
1087 también es un @code{note-event}, un @code{rhythmic-event}, y un
1088 @code{melodic-event}. Todas las clases de música están listadas en el
1089 manual de Referencia de funcionamiento interno, bajo el epígrafe
1090 @rinternals{Music classes}.
1093 objeto de C++: Cada objeto musical está representado por un objeto de
1094 la clase @code{Music} de C++.
1097 La información real de una expresión musical se almacena en
1098 propiedades. Por ejemplo, un @rinternals{NoteEvent} tiene propiedades
1099 @code{pitch} y @code{duration} que almacenan la altura y la duración
1100 de esa nota. Hay una lista de todas la propiedades disponibles en el
1101 manual de Referencia de funcionamiento interno, bajo el epígrafe
1102 @rinternals{Music properties}.
1104 Una expresión musical compuesta es un objeto musical que contiene
1105 otros objetos musicales dentro de sus propiedades. Se puede almacenar
1106 una lista de objetos dentro de la propiedad @code{elements} de un
1107 objeto musical, o un único objeto musical @q{hijo} dentro de la
1108 propiedad @code{element}. Por ejemplo, @rinternals{SequentialMusic}
1109 tiene su hijo dentro de @code{elements}, y @rinternals{GraceMusic}
1110 tiene su argumento único dentro de @code{element}. El cuerpo de una
1111 repetición se almacena dentro de la propiedad @code{element} de
1112 @rinternals{RepeatedMusic}, y las alternativas dentro de
1115 @node Construir funciones complicadas
1116 @section Construir funciones complicadas
1117 @translationof Building complicated functions
1119 Esta sección explica cómo reunir la información necesaria para crear
1120 funciones musicales complicadas.
1123 * Presentación de las expresiones musicales::
1124 * Propiedades musicales::
1125 * Duplicar una nota con ligaduras (ejemplo)::
1126 * Añadir articulaciones a las notas (ejemplo)::
1130 @node Presentación de las expresiones musicales
1131 @subsection Presentación de las expresiones musicales
1132 @translationof Displaying music expressions
1134 @cindex almacenamiento interno
1135 @cindex imprimir expresiones musicales
1136 @cindex representación interna, impresión de
1137 @cindex displayMusic
1138 @funindex \displayMusic
1140 Si se está escribiendo una función musical, puede ser muy instructivo
1141 examinar cómo se almacena internamente una expresión musical. Esto se
1142 puede hacer con la función musical @code{\displayMusic}
1146 \displayMusic @{ c'4\f @}
1151 imprime lo siguiente:
1161 'AbsoluteDynamicEvent
1165 (ly:make-duration 2 0 1 1)
1167 (ly:make-pitch 0 0 0))))
1170 De forma predeterminada, LilyPond imprime estos mensajes sobre la
1171 consola junto al resto de los mensajes. Para separar estos mensajes y
1172 guardar el resultado de @code{\display@{LOQUESEA@}}, redirija la
1173 salida a un archivo.
1176 lilypond archivo.ly >salida.txt
1179 Con un poco de magia combinada de LilyPond y Scheme, podemos realmente
1180 hacer que LilyPond dirija solamente esta salida a su propio archivo:
1184 #(with-output-to-file "display.txt"
1185 (lambda () #@{ \displayMusic @{ c'4\f @} #@}))
1190 Un poco de reformateo hace a la información anterior más fácil de
1194 (make-music 'SequentialMusic
1196 (make-music 'NoteEvent
1197 'articulations (list
1198 (make-music 'AbsoluteDynamicEvent
1201 'duration (ly:make-duration 2 0 1 1)
1202 'pitch (ly:make-pitch 0 0 0))))
1205 Una secuencia musical @code{@{ ... @}} tiene el nombre
1206 @code{SequentialMusic}, y sus expresiones internas se almacenan coma
1207 una lista dentro de su propiedad @code{'elements}. Una nota se
1208 representa como un objeto @code{NoteEvent} (que almacena las
1209 propiedades de duración y altura) con información adjunta (en este
1210 caso, un evento @code{AbsoluteDynamicEvent} con una propiedad
1211 @code{"f"} de texto) almacenada en su propiedad @code{articulations}.
1214 @code{\displayMusic} devuelve la música que imprime en la consola, y
1215 por ello se interpretará al tiempo que se imprime en la consola. Para
1216 evitar la interpretación, escriba @code{\void} antes de
1217 @code{\displayMusic}.
1219 @node Propiedades musicales
1220 @subsection Propiedades musicales
1221 @translationof Music properties
1223 @c TODO -- make sure we delineate between @emph{music} properties,
1224 @c @emph{context} properties, and @emph{layout} properties. These
1225 @c are potentially confusing.
1231 \displayMusic \someNote
1236 (ly:make-duration 2 0 1 1)
1238 (ly:make-pitch 0 0 0))
1241 The @code{NoteEvent} object is the representation of @code{someNote}.
1242 Straightforward. How about putting c' in a chord?
1246 \displayMusic \someNote
1254 (ly:make-duration 2 0 1 1)
1256 (ly:make-pitch 0 0 0))))
1259 Ahora el objeto @code{NoteEvent} es el primer objeto
1260 de la propiedad @code{'elements} de @code{someNote}.
1262 La función @code{display-scheme-music} es la función que se usa por
1263 parte de @code{\displayMusic} para imprimir la representación de
1264 Scheme de una expresión musical.
1267 #(display-scheme-music (first (ly:music-property someNote 'elements)))
1272 (ly:make-duration 2 0 1 1)
1274 (ly:make-pitch 0 0 0))
1277 Después se accede a la altura de la nota a través de la propiedad
1278 @code{'pitch} del objeto @code{NoteEvent}:
1281 #(display-scheme-music
1282 (ly:music-property (first (ly:music-property someNote 'elements))
1285 (ly:make-pitch 0 0 0)
1288 La altura de la nota se puede cambiar estableciendo el valor de esta
1289 propiedad @code{'pitch},
1291 @funindex \displayLilyMusic
1294 #(set! (ly:music-property (first (ly:music-property someNote 'elements))
1296 (ly:make-pitch 0 1 0)) ;; establecer la altura a d'.
1297 \displayLilyMusic \someNote
1303 @node Duplicar una nota con ligaduras (ejemplo)
1304 @subsection Duplicar una nota con ligaduras (ejemplo)
1305 @translationof Doubling a note with slurs (example)
1307 Supongamos que queremos crear una función que convierte una entrada
1308 como @code{a} en @code{@{ a( a) @}}. Comenzamos examinando la
1309 representación interna de la música con la que queremos terminar.
1312 \displayMusic@{ a'( a') @}
1325 (ly:make-duration 2 0 1 1)
1327 (ly:make-pitch 0 5 0))
1336 (ly:make-duration 2 0 1 1)
1338 (ly:make-pitch 0 5 0))))
1341 La mala noticia es que las expresiones @code{SlurEvent} se deben
1342 añadir @q{dentro} de la nota (dentro de la
1343 propiedad @code{articulations}).
1345 Ahora examinamos la entrada,
1353 (ly:make-duration 2 0 1 1)
1355 (ly:make-pitch 0 5 0))))
1358 Así pues, en nuestra función, tenemos que clonar esta expresión (de
1359 forma que tengamos dos notas para construir la secuencia), añadir
1360 @code{SlurEvent} a la propiedad @code{'articulations} de cada una de
1361 ellas, y por último hacer una secuencia @code{SequentialMusic} con los
1362 dos @code{EventChords}. Para añadir a una propiedad, es útil saber
1363 que una propiedad no establecida se lee como @code{'()}, la lista
1364 vacía, así que no se requiere ninguna comprobación especial antes de
1365 que pongamos otro elemento delante de la propiedad
1366 @code{articulations}.
1370 doubleSlur = #(define-music-function (parser location note) (ly:music?)
1371 "Return: @{ note ( note ) @}.
1372 `note' is supposed to be a single note."
1373 (let ((note2 (ly:music-deep-copy note)))
1374 (set! (ly:music-property note 'articulations)
1375 (cons (make-music 'SlurEvent 'span-direction -1)
1376 (ly:music-property note 'articulations)))
1377 (set! (ly:music-property note2 'articulations)
1378 (cons (make-music 'SlurEvent 'span-direction 1)
1379 (ly:music-property note2 'articulations)))
1380 (make-music 'SequentialMusic 'elements (list note note2))))
1384 @node Añadir articulaciones a las notas (ejemplo)
1385 @subsection Añadir articulaciones a las notas (ejemplo)
1386 @translationof Adding articulation to notes (example)
1388 La manera fácil de añadir articulación a las notas es mezclar dos
1389 expresiones musicales en un solo contexto, como se explica en
1390 @ruser{Crear contextos}. Sin embargo, supongamos que queremos
1391 escribir una función musical que lo haga. Esto tiene la ventaja
1392 adicional de que podemos usar esa función musical para añadir una
1393 articulación (como una instrucción de digitación) a una nota única
1394 dentro de un acorde, lo cual no es posible si nos limitamos a mezclar
1395 fragmentos de música independientes.
1397 Una @code{$variable} dentro de la notación @code{#@{...#@}} es como
1398 una @code{\variable} normal en la notación clásica de LilyPond.
1406 no funciona en LilyPond. Podríamos evitar este problema adjuntando la
1407 articulación a un acorde vacío,
1410 @{ << \music <> -. -> >> @}
1414 pero a los efectos de este ejemplo, aprenderemos ahora cómo hacerlo en
1415 Scheme. Empezamos examinando nuestra entrada y la salida deseada,
1424 (ly:make-duration 2 0 1 1)
1426 (ly:make-pitch -1 0 0))))
1439 (ly:make-duration 2 0 1 1)
1441 (ly:make-pitch -1 0 0))
1444 Vemos que una nota (@code{c4}) se representa como una expresión
1445 @code{NoteEvent}. Para añadir una articulación de acento, se debe
1446 añadir una expresión @code{ArticulationEvent} a la propiedad
1447 @code{articulations} de la expresión @code{NoteEvent}.
1449 Para construir esta función, empezamos con
1452 (define (add-accent note-event)
1453 "Add an accent ArticulationEvent to the articulations of `note-event',
1454 which is supposed to be a NoteEvent expression."
1455 (set! (ly:music-property note-event 'articulations)
1456 (cons (make-music 'ArticulationEvent
1457 'articulation-type "accent")
1458 (ly:music-property note-event 'articulations)))
1462 La primera línea es la forma de definir una función en Scheme: el
1463 nombre de la función es @code{add-accent}, y tiene una variable
1464 llamada @code{note-event}. En Scheme, el tipo de variable suele
1465 quedar claro a partir de su nombre (¡esto también es una buena
1466 práctica en otros lenguajes de programación!)
1473 es una descripción de lo que hace la función. No es estrictamente
1474 necesaria, pero de igual forma que los nombres claros de variable, es
1477 Se preguntará porqué modificamos el evento de nota directamente en
1478 lugar de trabajar sobre una copia (se puede usar
1479 @code{ly:music-deep-copy} para ello). La razón es un contrato
1480 silencioso: se permite que las funciones musicales modifiquen sus
1481 argumentos; o bien se generan partiendo de cero (como la entrada del
1482 usuario) o están ya copiadas (referenciar una variable de música con
1483 @samp{\name} o la música procedente de expresiones de Scheme
1484 inmediatas @samp{$(@dots{})} proporcionan una copia). Dado que sería
1485 ineficiente crear copias innecesarias, el valor devuelto de una
1486 función musical @emph{no} se copia. Así pues, para cumplir dicho
1487 contrato, no debemos usar ningún argumento más de una vez, y
1488 devolverlo cuenta como una vez.
1490 En un ejemplo anterior, hemos construido música mediante la repetición
1491 de un argumento musical dado. En tal caso, al menos una repetidión
1492 tuvo que ser una copia de sí misma. Si no lo fuese, podrían ocurrir
1493 cosas muy extrañas. Por ejemplo, si usamos @code{\relative} o
1494 @code{\transpose} sobre la música resultante que contiene los mismos
1495 elementos varias veces, estarían sujetos varias veces a la
1496 relativización o al transporte. Si los asignamos a una variable de
1497 música, se rompe el curso porque hacer referencia a @samp{\name}
1498 creará de nuevo una copia que no retiene la identidad de los elementos
1501 Ahora bien, aun cuando la función anterior no es una función musical,
1502 se usará normalmente dentro de funciones musicales. Así pues, tiene
1503 sentido obedecer el mismo convenio que usamos para las funciones
1504 musicales: la entrada puede modificarse para producir la salida, y el
1505 código que llama es responsable de crear las copias si aún necesita el
1506 propio argumento sin modificar. Si observamos las propias funciones
1507 de LilyPond como @code{music-map}, veremos que se atienen a los mismos
1510 ¿En qué punto nos encontramos? Ahora tenemos un @code{note-event} que
1511 podemos modificar, no a causa de la utilización de
1512 @code{ly:music-deep-copy} sino por una explicación muy desarrollada.
1513 Añadimos el acento a su propiedad de lista @code{'articulations}.
1516 (set! place new-value)
1519 Aquí, lo que queremos establecer (el @q{place}) es la propiedad
1520 @code{'articulations} de la expresión @code{note-event}.
1523 (ly:music-property note-event 'articulations)
1526 @code{ly:music-property} es la función ustilizada para acceder a las
1527 propiedades musicales (las @code{'articulations}, @code{'duration},
1528 @code{'pitch}, etc, que vemos arriba en la salida de
1529 @code{\displayMusic}). El nuevo valor es la antigua propiedad
1530 @code{'articulations}, con un elemento adicional: la expresión
1531 @code{ArticulationEvent}, que copiamos a partir de la salida de
1532 @code{\displayMusic},
1535 (cons (make-music 'ArticulationEvent
1536 'articulation-type "accent")
1537 (ly:music-property result-event-chord 'articulations))
1540 Se usa @code{cons} para añadir un elemento a la parte delantera de una
1541 lista sin modificar la lista original. Esto es lo que queremos: la
1542 misma lista de antes, más la nueva expresión @code{ArticulationEvent}.
1543 El orden dentro de la propiedad @code{'articulations} no tiene
1546 Finalmente, una vez hemos añadido la articulación de acento a su
1547 propiedad @code{articulations}, podemos devolver @code{note-event}, de
1548 aquí la última línea de la función.
1550 Ahora transformamos la función @code{add-accent} en una función
1551 musical (es cuestión de un poco de aderezo sintáctico y una
1552 declaración del tipo de su único argumento @q{real}).
1555 addAccent = #(define-music-function (parser location note-event)
1557 "Add an accent ArticulationEvent to the articulations of `note-event',
1558 which is supposed to be a NoteEvent expression."
1559 (set! (ly:music-property note-event 'articulations)
1560 (cons (make-music 'ArticulationEvent
1561 'articulation-type "accent")
1562 (ly:music-property note-event 'articulations)))
1566 Podemos verificar que esta función musical funciona correctamente:
1569 \displayMusic \addAccent c4
1575 * Trucos con Scheme::
1578 @c @nod e Trucos con Scheme
1579 @c @sectio n Trucos con Scheme
1580 @c @transl ationof Tweaking with Scheme
1582 Hemos visto cómo la salida de LilyPond se puede modificar
1583 profundamente usando instrucciones como @code{\override TextScript.extra-offset = ( 1 . -1)}. Pero tenemos incluso mucho más poder si
1584 utilizamos Scheme. Para ver una explicación completa de esto,
1585 consulte el @ref{Tutorial de Scheme}, y @ruser{Interfaces para programadores}.
1587 Podemos usar Scheme simplemente para sobreescribir instrucciones con
1590 TODO Find a simple example
1591 @c This isn't a valid example with skylining
1592 @c It works fine without padText -td
1596 @lilypond[quote,verbatim,ragged-right]
1597 padText = #(define-music-function (parser location padding) (number?)
1599 \once \override TextScript.padding = #padding
1603 c4^"piu mosso" b a b
1605 c4^"piu mosso" d e f
1607 c4^"piu mosso" fis a g
1613 Lo podemos usar para crear instrucciones nuevas:
1615 @c Check this is a valid example with skylining
1616 @c It is - 'padding still works
1619 @lilypond[quote,verbatim,ragged-right]
1620 tempoPadded = #(define-music-function (parser location padding tempotext)
1623 \once \override Score.MetronomeMark.padding = #padding
1624 \tempo \markup { \bold #tempotext }
1628 \tempo \markup { "Low tempo" }
1630 \tempoPadded #4.0 "High tempo"
1636 Incluso se le pueden pasar expresiones musicales:
1638 @lilypond[quote,verbatim,ragged-right]
1639 pattern = #(define-music-function (parser location x y) (ly:music? ly:music?)
1646 \pattern {d16 dis} { ais16-> b\p }