1 @c -*- coding: utf-8; mode: texinfo; documentlanguage: es -*-
2 @c This file is part of extending.tely
4 Translation of GIT committish: fc43a05568a1be2fc78bd7a16a42e474d239aac8
6 When revising a translation, copy the HEAD committish of the
7 version that you are working on. See TRANSLATION for details.
12 @node Interfaces para programadores
13 @chapter Interfaces para programadores
14 @translationof Interfaces for programmers
16 Se pueden realizar trucos avanzados mediante el uso de Scheme. Si no
17 está familiarizado con Scheme, le conviene leer nuestro tutorial de
18 Scheme, @ref{Tutorial de Scheme}.
22 * Bloques de código de LilyPond::
23 * Funciones de Scheme::
24 * Funciones musicales::
25 * Funciones de eventos::
26 * Funciones de marcado::
27 * Contextos para programadores::
28 * Funciones de callback::
29 * Código de Scheme en línea::
33 @node Bloques de código de LilyPond
34 @section Bloques de código de LilyPond
35 @translationof LilyPond code blocks
37 @cindex Bloques de código de LilyPond
38 @cindex LilyPond, bloques de código de
39 @funindex #@{ @dots{} #@}
43 La creación de expresiones musicales en Scheme puede ser una tarea
44 tediosa porque a veces presentan muchos niveles de profundidad de
45 anidamiento y el código resultante es grande. Para algunas tareas
46 sencillas, esto puede evitarse utilizando bloques de código de
47 LilyPond, que permiten usar la sintaxis ordinaria de LilyPond
50 Los bloques de código de LilyPond tienen el siguiente aspecto:
52 #@{ @var{código de LilyPond} #@}
55 He aquí un ejemplo trivial:
57 @lilypond[verbatim,quote]
58 ritpp = #(define-event-function (parser location) ()
65 Los bloques de código de LilyPond se pueden usar en cualquier
66 lugar en el que se pueda escribir código de Scheme. El lector de
67 Scheme en efecto se modifica para que pueda incorporar bloques de
68 código de LilyPond y pueda ocuparse de las expresiones de Scheme
69 incrustadas que comienzan por @code{$} y@w{ }@code{#}.
71 @cindex parser (function argument)
74 El lector extrae el bloque de código de LilyPond y genera una
75 llamada en tiempo de ejecución al analizador sintáctico para que
76 interprete el código de LilyPond. Las expresiones de Scheme
77 incrustadas en el código de LilyPond se evalúan dentro del entorno
78 lóexico del bloque de código de LilyPond, de manera que puede
79 accederse a todas las variables locales y los parámetros de
80 función que están disponibles en el punto en que se escribe el
81 bloque de código de LilyPond. Las variables definidas en otros
82 módulos de Scheme, como los módulos que contienen bloques
83 @code{\header} y @code{\layout}, no están accesibles como
84 variables de Scheme, es decir, precedidas de@tie{}@code{#}, pero
85 se puede acceder a ellas como variables de LilyPond, es decir,
86 precedidas de@tie{}@code{\}.
88 Si @code{location} (véase @ref{Funciones de Scheme}) se refiere a una
89 posición de entrada válida (como lo hace normalmente dentro de las
90 funciones musicales o de Scheme), toda la música generada dentro
91 del bloque de código tiene su @samp{origin} establecido a
94 Un bloque de código de LilyPond puede contener cualquier cosa que
95 podríamos utilizar en la parte derecha de una asignación. Además, un
96 bloque de LilyPond vacío corresponde a una expresión musical vacía, y
97 un bloque de LilyPond que contiene varios eventos musicales se
98 convierte en una expresión de música secuencial.
100 @node Funciones de Scheme
101 @section Funciones de Scheme
102 @translationof Scheme functions
103 @cindex Scheme, funciones de (sintaxis de LilyPond)
105 Las @emph{funciones de Scheme} son procedimientos de Scheme que pueden
106 crear expresiones de Scheme a partir de código de entrada escrito en
107 la sintaxis de LilyPond. Se pueden llamar desde prácticamente
108 cualquier lugar en el que se permita el uso de @code{#} para la
109 especificación de un valor en sintaxis de Scheme. Mientras que Scheme
110 tiene funciones propias, este capítulo se ocupa de las funciones
111 @emph{sintácticas}, funciones que reciben argumentos especificados en
112 la sintaxis de LilyPond.
115 * Definición de funciones de Scheme::
116 * Uso de las funciones de Scheme::
117 * Funciones de Scheme vacías::
120 @node Definición de funciones de Scheme
121 @subsection Definición de funciones de Scheme
122 @translationof Scheme function definitions
123 @funindex define-scheme-function
125 La forma general de la definición de una función de Scheme es:
129 #(define-scheme-function
130 (parser location @var{arg1} @var{arg2} @dots{})
131 (@var{tipo1?} @var{tipo2?} @dots{})
138 @multitable @columnfractions .33 .66
140 @tab tiene que ser literalmente @code{parser} para dar a los bloques de código
141 de LilyPond (@code{#@{}@dots{}@code{#@}}) acceso al analizador
144 @item @code{location}
145 @tab tiene que ser literalmente @code{location} para ofrecer acceso al
146 objeto de situación de la entrada, que se usa para ofrecer
147 menssajes de error con nombres de archivo y números de línea.
149 @item @code{@var{argN}}
150 @tab @var{n}-ésimo argumento
152 @item @code{@var{typeN?}}
153 @tab un @emph{predicado de tipo} de Scheme para el que @code{@var{argN}}
154 debe devolver @code{#t}. Algunos de estos predicados se reconocen
155 de forma especial por parte del analizador, véase más abajo.
156 También existe una forma especial @code{(@emph{predicate?}
157 @emph{default})} para especificar argumentos opcionales. Si el
158 argumento actual no está presente cuando se ll ama a la función,
159 el valor predeterminado se emplea en sustitución. Los valores
160 predeterminados se evalúan en tiempo de definición (¡incluyendo
161 los bloques de código de LilyPond!), de manera que se necesitamos
162 un valor por omisión calculado en tiempo de ejecución, debemos
163 escribir en su lugar un valor especial que podamos reconocer
164 fácilmente. Si escribimos el predicado entre paréntesis pero no
165 lo seguimos por el valor predeterminado, se usa @code{#f} como
166 valor por omisión. Los valores por omisión no se verifican con
167 @emph{predicate?} en tiempo de definición ni en tiempo de
168 ejecución: es nuestra responsabilidad tratar con los valores que
169 especifiquemos. Los valores por omisión que son expresiones
170 musicales se copian mientras se establece @code{origin} al
171 parámetro @code{location}.
173 @item @code{@var{cuerpo}}
174 @tab una secuencia de formas de Scheme que se evalúan ordenadamente; la
175 última forma de la secuencia se usa como el valor de retorno de la
176 función de Scheme. Puede contener bloques de código de LilyPond
177 encerrados entre llaves con almohadillas
178 (@tie{}@w{@code{#@{@dots{}#@}}}@tie{}), como se describe en
179 @ref{Bloques de código de LilyPond}. Dentro de los bloques de código
180 de LilyPond, use el símbolo @code{#} para hacer referencia a
181 argumentos de función (p.ej. @samp{#arg1}) o para iniciar una
182 expresión en línea de Scheme que contenga argumentos de función
183 (p.ej. @w{@samp{#(cons arg1 arg2)}}). Donde las expresiones de Scheme
184 normales que usan @code{#} no funcionan, podríamos necesitar volver a
185 expresiones de Scheme inmediatas que usan @code{$}, como por ejemplo
188 Si nuestra función devuelve una expresión musical, recibe un valor
193 Ciertos predicados de tipo se manejan de forma especial por parte del
194 analizador sintáctico ya que de otro modo éste no es capaz de
195 reconocer los argumentos eficientemente. Actualmente son
196 @code{ly:pitch?} y @code{ly:duration?}.
198 La idoneidad de lpos argumentos para el resto de los predicados viene
199 determinada mediante llamadas reales al predicado después de que
200 LilyPond ya las ha convertido en una expresión de Scheme. Como
201 consecuencia, el argumento se puede especificar en la sintaxis de
202 Scheme si se desea (precedido de @code{#} o como resultado de haber
203 llamado a una función de Scheme), pero LilyPond también convierte
204 algunas construcciones de LilyPond en Scheme antes de hacer
205 efectivamente la comprobación del predicado sobre ellas. Actualmente
206 se encuentran entre ellas la música, los post-eventos, las cadenas
207 simples (entrecomilladas o no), los números, los elementos de marcado
208 y de listas de marcado, score (partitura), book (libro), bookpart
209 (parte de libro), las definiciones de contexto y los bloques de
210 definición de salida.
212 Para ciertos tipos de expresión (como la mayor parte de la música que
213 no está encerrada entre llaves) LilyPond necesita más allá de la
214 expresión misma para poder determinar su final. Si tal expresión se
215 considerase un argumento opcional mediante la evaluación de su
216 predicado, LilyPond no podría recuperarse después de decidir que la
217 expresión no se corresponde con el parámetro. Así, ciertas formas de
218 música necesitan ir encerradas entre llaves para que LilyPond pueda
219 aceptarlas. Existen también otras ambigüedades que LilyPond resuelve
220 mediante la comprobación con funciones de predicado: ¿es @samp{-3} un
221 post-evento de digitación o un nnúmero negativo? ¿Es @code{"a" 4} en
222 el modo de letra una cadena seguida por un número, o un evento de
223 letra con la duración @code{4}? LilyPond lo decide preguntándole a
224 los predicados. Ello significa que un debemos evitar los
225 predicados permisivos como @code{scheme?} si tenemos en mente
226 un uso particular en vez de una función de uso general.
228 Para ver una lista de los predicados de tipo disponibles, consulte
229 @ruser{Predicados de tipo predefinidos}.
233 Referencia de la notación:
234 @ruser{Predicados de tipo predefinidos}.
237 @file{lily/music-scheme.cc},
242 @node Uso de las funciones de Scheme
243 @subsection Uso de las funciones de Scheme
244 @translationof Scheme function usage
246 Las funciones de Scheme se pueden llamar casi desde cualquier lugar en
247 que puede escribirse una expresión de Scheme que comience con la
248 almohadilla@tie{}@code{#}. Llamamos a una función de Scheme
249 escribiendo su nombre precedido de la barra invertida@tie{}@code{\}, y
250 seguido por sus argumentos. Una vez que un argumento opcional no
251 corresponde a ningún argumento, LilyPond se salta este argumento y
252 todos los que le siguen, sustituyéndolos por su valor por omisión
253 especificado, y @q{recupera} el argumento que no correspondía al lugar
254 del siguiente argumento obligatorio. Dado que el argumento recuperado
255 necesita ir a algún lugar, los argumentos opcionales no se consideran
256 realmente opcionales a no ser que vayan seguidos de un argumento
259 Existe una excepción: si escribimos @code{\default} en el lugar de un
260 argumento opcional, este argumento y todos los argumentos opcionales
261 que le siguen se saltan y se sustituyen por sus valores
262 predeterminados. Esto funciona incluso si no sigue ningún argumento
263 obligatorio porque @code{\default} no necesita recuperarse. Las
264 instrucciones @code{mark} y @code{key} hacen uso de este truco para
265 ofrecer su comportamiento predeterminado cuando van seguidas solamente
268 Aparte de los lugares en que se requiere un valor de Scheme hay
269 ciertos sitios en que se aceptan expresiones de almohadilla @code{#} y
270 se evalúan por sus efectos secundarios, pero por lo demás se ignoran.
271 Son, mayormente, los lugares en que también sería aceptable colocar
274 Dado que no es buena idea devolver valores que puedan malinterpretarse
275 en algún contexto, debería usar funciones de Scheme normales solo para
276 los casos en que siempre se devuelve un valor útil, y usar funciones
277 de Scheme vacías (@pxref{Funciones de Scheme vacías}) en caso
281 @node Funciones de Scheme vacías
282 @subsection Funciones de Scheme vacías
283 @translationof Void scheme functions
284 @funindex define-void-function
287 En ocasiones, un procedimiento se ejecuta con el objeto de llevar a
288 cabo alguna acción más que para devolver un valor. Algunos lenguajes
289 de programación (como C y Scheme) usan las funciones para los dos
290 conceptos y se limitan a descartar el valor devuelto (usualmente
291 haciendo que cualquier expresión pueda actuar como instrucción,
292 ignorando el resultado devuelto). Esto puede parecer inteligente pero
293 es propenso a errores: casi todos los compiladores de C de hoy en día
294 emiten advertencias cuando se descarta una expresión no vacía. Para
295 muchas funciones que ejecutan una acción, los estándares de Scheme
296 declaran que el valor de retorno sea no especificado. Guile, el
297 intérprete de Scheme de LilyPond, tiene un valor único
298 @code{*unspecified*} que en tales casos devuelve de forma usual (como
299 cuando se usa directamente @code{set!} sobre una variable), pero
300 desgraciadamente no de forma consistente.
302 Definir una función de LilyPond con @code{define-void-function}
303 asegura que se devuelve este valor especial, el único valor que
304 satisface el predicado @code{void?}.
308 #(define-void-function
311 (ly:set-option 'point-and-click #f))
313 \noApuntarYPulsar % desactivar la función de apuntar y pulsar
316 Si queremos evaluar una expresión sólo por su efecto colateral y no
317 queremos que se interprete ningún valor que pueda devolver, podemos
318 hacerlo anteponiendo el prefijo @code{\void}:
321 \void #(hashq-set! some-table some-key some-value)
324 De esta forma podemos asegurar que LilyPond no asignará ningún
325 significado al valor devuelto, independientemente de dónde lo
326 encuentre. También funciona para funciones musicales como
327 @code{\displayMusic}.
329 @node Funciones musicales
330 @section Funciones musicales
331 @translationof Music functions
333 @cindex funciones musicales
335 Las @emph{funciones musicales} son procedimientos de Scheme que pueden
336 crear automáticamente expresiones musicales, y se pueden usar para
337 simplificar enormemente el archivo de entrada.
340 * Definiciones de funciones musicales::
341 * Uso de las funciones musicales::
342 * Funciones de sustitución sencillas::
343 * Funciones de sustitución intermedias::
344 * Matemáticas dentro de las funciones::
345 * Funciones sin argumentos::
346 * Funciones musicales vacías::
350 @node Definiciones de funciones musicales
351 @subsection Definiciones de funciones musicales
352 @translationof Music function definitions
353 @cindex definición de funciones musicales
354 @funindex define-music-function
356 La forma general para definir funciones musicales es:
360 #(define-music-function
361 (parser location @var{arg1} @var{arg2} @dots{})
362 (@var{tipo1?} @var{tipo2?} @dots{})
367 de forma bastante análoga a @ref{Definición de funciones de Scheme}.
368 Lo más probable es que el @var{cuerpo} sea un
369 @ref{Bloques de código de LilyPond,bloque de código de LilyPond}.
371 Para ver una lista de los predicados de tipo disponibles, consulte
372 @ruser{Predicados de tipo predefinidos}.
376 Referencia de la notación:
377 @ruser{Predicados de tipo predefinidos}.
380 @file{lily/music-scheme.cc},
385 @node Uso de las funciones musicales
386 @subsection Uso de las funciones musicales
387 @translationof Music function usage
389 Las funciones musicales se pueden actualmente utilizar en varios
390 lugares. Dependiendo de dónde se usan, son de aplicación ciertas
391 restricciones para que sea posible su análisis sintáctico de forma
392 no ambigua. El resultado que devuelve una función musical debe ser
393 compatible con el contexto desde el que se la llama.
397 En el nivel superior dentro de una expresión musical. Aquí
398 no se aplica ninguna restricción.
401 Como un post-evento, que comienza explícitamente con un indicador de
402 dirección (a elegir entre @code{-}, @code{^} @w{y @code{_}}).
403 Observe que se puede aceptar la devolución de un
404 post-evento por parte de las funciones musicales que se llaman como
405 música normal, lo que lleva a un resultado aproximadamente equivalente
411 En este caso, no podemos usar una expresión musical @emph{abierta}
412 como último argumento, que terminaría en una expresión musical
413 capaz de aceptar post-eventos adicionales.
416 Como componente de un acorde. La expresión devuelta debe ser
417 del tipo @code{rhythmic-event}, probablemente un @code{NoteEvent}.
421 Las reglas especiales para los argumentos del final hacen posible
422 escribir funciones polimórficas como @code{\tweak} que se pueden
423 aplicar a construcciones distintas.
425 @node Funciones de sustitución sencillas
426 @subsection Funciones de sustitución sencillas
427 @translationof Simple substitution functions
429 Una función de sustitución sencilla es una función musical cuya
430 expresión musical de salida está escrita en código de LilyPond
431 y contiene argumentos de la función en la expresión de salida.
432 Están descritas en @ruser{Ejemplos de funciones de sustitución}.
435 @node Funciones de sustitución intermedias
436 @subsection Funciones de sustitución intermedias
437 @translationof Intermediate substitution functions
439 Las funciones de sustitución intermedias contienen una
440 mezcla de código de Scheme y de LilyPond
441 dentro de la expresión musical que se devuelve.
443 Algunas instrucciones @code{\override} requieren un argumento que
444 consiste en una pareja de números (llamada una @emph{célula cons} en
447 La pareja se puede pasar directamente dentro de la función musical,
448 usando una variable @code{pair?}:
452 #(define-music-function
453 (parser location principio-final)
456 \once \override Beam.positions = #principio-final
460 \barraManual #'(3 . 6) c8 d e f
464 De forma alternativa, los números que componen la pareja se pueden
465 pasar como argumentos separados, y el código de Scheme que se ha usado
466 para crear la pareja se puede incluir dentro de la expresión musical:
468 @lilypond[quote,verbatim,ragged-right]
470 #(define-music-function
471 (parser location beg end)
474 \once \override Beam.positions = #(cons beg end)
478 \manualBeam #3 #6 c8 d e f
483 @cindex sobreescrituras temporales
484 @cindex temporales, sobreescrituras
485 @cindex propiedades, recuperar valor anterior
487 Las propiedades se mantienen conceptualmente utilizando una pila
488 por cada propiedad, por cada grob y por cada contexto. Las
489 funciones musicales pueden requerir la sobreescritura de una o
490 varias propiedades durante el tiempo de duración de la función,
491 restaurándolas a sus valores previos antes de salir. Sin embargo,
492 las sobreescrituras normales extraen y descartan la cima de la
493 pila de propiedades actual antes de introducir un valor en ella,
494 de manera que el valor anterior de la propiedad se pierde cuando
495 se sobreescribe. Si se quiere preservar el valor anterior, hay
496 que preceder la instrucción @code{\override} con la palabra clave
497 @code{\temporary}, así:
500 \temporary \override @dots{}
503 El uso de @code{\temporary} hace que se borre la propiedad
504 (normalmente fijada a un cierto valor) @code{pop-first} de la
505 sobreescritura, de forma que el valor anterior no se extrae de la
506 pila de propiedades antes de poner en ella el valor nuevo. Cuando
507 una instrucción @code{\revert} posterior extrae el avlor
508 sobreescrito temporalmente, volverá a emerger el valor anterior.
510 En otras palabras, una llamada a @code{\temporary \override} y a
511 continuación otra a @code{\revert} sobre la misma propiedad, tiene
512 un valor neto que es nulo. De forma similar, la combinación en
513 secuencia de @code{\temporary} y @code{\undo} sobre la misma
514 música que contiene las sobreescrituras, tiene un efecto neto
517 He aquí un ejemplo de una función musical que utiliza lo expuesto
518 anteriormente. El uso de @code{\temporary} asegura que los
519 valores de las propiedades @code{cross-staff} y @code{style} se
520 restauran a la salida a los valores que tenían cuando se llamó a
521 la función @code{crossStaff}. Sin @code{\temporary}, a la salida
522 se habrían fijado los valores predeterminados.
526 #(define-music-function (parser location notes) (ly:music?)
527 (_i "Create cross-staff stems")
529 \temporary \override Stem.cross-staff = #cross-staff-connect
530 \temporary \override Flag.style = #'no-flag
532 \revert Stem.cross-staff
538 @node Matemáticas dentro de las funciones
539 @subsection Matemáticas dentro de las funciones
540 @translationof Mathematics in functions
542 Las funciones musicales pueden contar con programación de Scheme
543 además de la simple sustitución:
545 @lilypond[quote,verbatim,ragged-right]
547 #(define-music-function
548 (parser location mag)
551 \override Stem.length = #(* 7.0 mag)
552 \override NoteHead.font-size =
553 #(inexact->exact (* (/ 6.0 (log 2.0)) (log mag)))
558 \revert NoteHead.font-size
563 \AltOn #1.5 c c \AltOff c2
568 Este ejemplo se puede reescribir de forma que pase expresiones
571 @lilypond[quote,verbatim,ragged-right]
573 #(define-music-function
574 (parser location mag music)
577 \override Stem.length = #(* 7.0 mag)
578 \override NoteHead.font-size =
579 #(inexact->exact (* (/ 6.0 (log 2.0)) (log mag)))
582 \revert NoteHead.font-size
586 c2 \withAlt #0.5 { c4 c }
587 \withAlt #1.5 { c c } c2
592 @node Funciones sin argumentos
593 @subsection Funciones sin argumentos
594 @translationof Functions without arguments
596 En casi todos los casos, una función sin argumentos se debe escribir
600 dolce = \markup@{ \italic \bold dolce @}
603 Sin embargo, en raras ocasiones puede ser de utilidad crear una
604 función musical sin argumentos:
607 mostrarNumeroDeCompas =
608 #(define-music-function
611 (if (eq? #t (ly:get-option 'display-bar-numbers))
612 #@{ \once \override Score.BarNumber.break-visibility = ##f #@}
616 Para la impresión real de los números de compás donde se llama a esta
617 función, invoque a @command{lilypond} con
620 lilypond -d display-bar-numbers ARCHIVO.ly
624 @node Funciones musicales vacías
625 @subsection Funciones musicales vacías
626 @translationof Void music functions
628 Una función musical debe devolver una expresión musical. Si quiere
629 ejecutar una función exclusivamente por sus efectos secundarios,
630 debería usar @code{define-void-function}. Pero
631 puede haber casos en los que a veces queremos producir una expresión
632 musical, y a veces no (como en el ejemplo anterior). Devolver una
633 expresión musical @code{void} (vacía) por medio de @code{#@{ #@}} lo
637 @node Funciones de eventos
638 @section Funciones de eventos
639 @translationof Event functions
640 @funindex define-event-function
641 @cindex event functions
643 Para usar una función musical en el lugar de un evento, tenemos que
644 escribir un indicador de dirección antes de ella. Pero a veces, ello
645 hace que se pierda la correspondencia con la sintaxis de las
646 construcciones que queremos sustituir. Por ejemplo, si queremos
647 escribir instrucciones de matiz dinámico, éstos se adjuntan
648 habitualmente sin indicador de dirección, como @code{c'\pp}. He aquí
649 una forma de escribir indicaciones dinámicas arbitrarias:
651 @lilypond[quote,verbatim,ragged-right]
652 dyn=#(define-event-function (parser location arg) (markup?)
653 (make-dynamic-script arg))
654 \relative c' { c\dyn pfsss }
657 Podríamos hacer lo mismo usando una función musical, pero entonces
658 tendríamos que escribir siempre un indicador de dirección antes de
659 llamarla, como @code{@w{c-\dyn pfsss}}.
662 @node Funciones de marcado
663 @section Funciones de marcado
664 @translationof Markup functions
666 Los elementos de marcado están implementados como funciones de Scheme
667 especiales que producen un objeto @code{Stencil} dada una serie de
672 * Construcción de elementos de marcado en Scheme::
673 * Cómo funcionan internamente los elementos de marcado::
674 * Definición de una instrucción de marcado nueva::
675 * Definición de nuevas instrucciones de lista de marcado::
678 @node Construcción de elementos de marcado en Scheme
679 @subsection Construcción de elementos de marcado en Scheme
680 @translationof Markup construction in Scheme
682 @cindex marcado, definir instrucciones de
684 El macro @code{markup} construye expresiones de marcado en Scheme,
685 proporcionando una sintaxis similar a la de LilyPond. Por ejemplo:
688 (markup #:column (#:line (#:bold #:italic "hola" #:raise 0.4 "mundo")
689 #:larger #:line ("fulano" "fulanito" "menganito")))
695 #@{ \markup \column @{ \line @{ \bold \italic "hola" \raise #0.4 "mundo" @}
696 \larger \line @{ fulano fulanito menganito @} @} #@}
700 Este ejemplo muestra las principales reglas de traducción entre la
701 sintaxis del marcado normal de LilyPond y la sintaxis del marcado de
702 Scheme. La utilización de @code{#@{ @dots{} #@}} para escribir en la
703 sintaxis de LilyPond será con frecuencia lo más conveniente, pero
704 explicamos cómo usar la macro @code{markup} para obtener una solución
708 @multitable @columnfractions .3 .3
709 @item @b{LilyPond} @tab @b{Scheme}
710 @item @code{\markup marcado1} @tab @code{(markup marcado1)}
711 @item @code{\markup @{ marcado1 marcado2 @dots{} @}} @tab
712 @code{(markup marcado1 marcado2 @dots{} )}
713 @item @code{\instruccion} @tab @code{#:instruccion}
714 @item @code{\variable} @tab @code{variable}
715 @item @code{\center-column @{ @dots{} @}} @tab
716 @code{#:center-column ( @dots{} )}
717 @item @code{cadena} @tab @code{"cadena"}
718 @item @code{#argumento-de-scheme} @tab @code{argumento-de-scheme}
722 Todo el lenguaje Scheme está accesible dentro del macro @code{markup}.
723 Por ejemplo, podemos usar llamadas a funciones dentro de @code{markup}
724 para así manipular cadenas de caracteres. Esto es útil si se están
725 definiendo instrucciones de marcado nuevas (véase
726 @ref{Definición de una instrucción de marcado nueva}).
731 El argumento markup-list de instrucciones como @code{#:line},
732 @code{#:center} y @code{#:column} no puede ser una variable ni el
733 resultado de la llamada a una función.
736 (markup #:line (funcion-que-devuelve-marcados))
740 no es válido. Hay que usar las funciones @code{make-line-markup},
741 @code{make-center-markup} o @code{make-column-markup} en su lugar:
744 (markup (make-line-markup (funcion-que-devuelve-marcados)))
748 @node Cómo funcionan internamente los elementos de marcado
749 @subsection Cómo funcionan internamente los elementos de marcado
750 @translationof How markups work internally
752 En un elemento de marcado como
755 \raise #0.5 "ejemplo de texto"
759 @code{\raise} se representa en realidad por medio de la función
760 @code{raise-markup}. La expresión de marcado se almacena como
763 (list raise-markup 0.5 (list simple-markup "ejemplo de texto"))
766 Cuando el marcado se convierte en objetos imprimibles (Stencils o
767 sellos), se llama la función @code{raise-markup} como
771 @var{\objeto de marcado}
772 @var{lista de listas asociativas de propiedades}
774 @var{el marcado "ejemplo de texto"})
777 Primero la función @code{raise-markup} crea el sello para la cadena
778 @code{ejemplo de texto}, y después eleva el sello Stencil en 0.5
779 espacios de pentagrama. Este es un ejemplo bastante simple; en el
780 resto de la sección podrán verse ejemplos más complejos, así como en
781 @file{scm/define-markup-commands.scm}.
784 @node Definición de una instrucción de marcado nueva
785 @subsection Definición de una instrucción de marcado nueva
786 @translationof New markup command definition
788 Esta sección trata sobre la definición de nuevas instrucciones de
793 * Sintaxis de la definición de instrucciones de marcado::
794 * Acerca de las propiedades::
795 * Un ejemplo completo::
796 * Adaptación de instrucciones incorporadas::
799 @node Sintaxis de la definición de instrucciones de marcado
800 @unnumberedsubsubsec Sintaxis de la definición de instrucciones de marcado
801 @translationof Markup command definition syntax
803 Se pueden definir instrucciones de marcado nuevas usando el macro de
804 Scheme @code{define-markup-command}, en el nivel sintáctico superior.
807 (define-markup-command (@var{nombre-de-la-instruccion} @var{layout} @var{props} @var{arg1} @var{arg2} @dots{})
808 (@var{tipo-de-arg1?} @var{tipo-de-arg2?} @dots{})
809 [ #:properties ((@var{propiedad1} @var{valor-predeterminado1})
811 @dots{}command body@dots{})
817 @item @var{nombre-de-la-instruccion}
818 nombre de la instrucción de marcado
820 la definición de @q{layout} (disposición).
822 una lista de listas asociativas, que contienen todas las propiedades
825 argumento @var{i}-ésimo de la instrucción
826 @item @var{tipo-de-argi?}
827 predicado de tipo para el argumento @var{i}-ésimo
830 Si la instrucción utiliza propiedades de los argumentos @code{props},
831 se puede usar la palabra clave @code{#:properties} para especificar
832 qué propiedades se usan, así como sus valores predeterminados.
834 Los argumentos se distinguen según su tipo:
836 @item un marcado, que corresponde al predicado de tipo @code{markup?};
837 @item una lista de marcados, que corresponde al predicado de tipo
839 @item cualquier otro objeto de Scheme, que corresponde a predicados de tipo como
840 @code{list?}, @code{number?}, @code{boolean?}, etc.
843 No existe ninguna limitación en el orden de los argumentos (después de
844 los argumentos estándar @code{layout} y @code{props}). Sin embargo, las
845 funciones de marcado que toman un elemento de marcado como su último
846 argumento son un poco especiales porque podemos aplicarlas a una lista
847 de marcados y el resultado es una lista de marcados donde la función
848 de marcado (con los argumentos antecedentes especificados) se ha
849 aplicado a todos los elementos de la lista de marcados original.
851 Dado que la replicación de los argumentos precedentes para aplicar una
852 función de marcado a una lista de marcados es poco costosa
853 principalmente por los argumentos de Scheme, se evitan las caídas de
854 rendimiento simplemente mediante la utilización de argumentos de
855 Scheme para los argumentos antecedentes de las funciones de marcado
856 que toman un marcado como su último argumento.
858 @node Acerca de las propiedades
859 @unnumberedsubsubsec Acerca de las propiedades
860 @translationof On properties
862 Los argumentos @code{layout} y @code{props} de las instrucciones de
863 marcado traen a escena un contexto para la interpretación del marcado:
864 tamaño de la tipografía, grueso de línea, etc.
866 El argumento @code{layout} permite el acceso a las propiedades
867 definidas en los bloques @code{paper}, usando la función
868 @code{ly:output-def-lookup}. Por ejemplo, el grueso de línea (el
869 mismo que el que se usa en las partituras) se lee usando:
872 (ly:output-def-lookup layout 'line-width)
875 El argumento @code{props} hace accesibles algunas propiedades a las
876 instrucciones de marcado. Por ejemplo, cuando se interpreta el
877 marcado del título de un libro, todas las variables definidas dentro
878 del bloque @code{\header} se añaden automáticamente a @code{props}, de
879 manera que el marcado del título del libro puede acceder al título del
880 libro, el autor, etc. También es una forma de configurar el
881 comportamiento de una instrucción de marcado: por ejemplo, cuando una
882 instrucción utiliza tamaños de tipografía durante el procesado, el
883 tamaño se lee de @code{props} en vez de tener un argumento
884 @code{font-size}. El que llama a una instrucción de marcado puede
885 cambiar el valor de la propiedad del tamaño de la tipografía con el
886 objeto de modificar el comportamiento. Utilice la palabra clave
887 @code{#:properties} de @code{define-markup-command} para especificar
888 qué propiedades se deben leer a partir de los argumentos de
891 El ejemplo de la sección siguiente ilustra cómo acceder y
892 sobreescribir las propiedades de una instrucción de marcado.
895 @node Un ejemplo completo
896 @unnumberedsubsubsec Un ejemplo completo
897 @translationof A complete example
899 El ejemplo siguiente define una instrucción de marcado para trazar un
900 rectángulo doble alrededor de un fragmento de texto.
902 En primer lugar, necesitamos construir un resultado aproximado
903 utilizando marcados. Una consulta a @ruser{Instrucciones de marcado
904 de texto} nos muestra que es útil la instrucción @code{\box}:
906 @lilypond[quote,verbatim,ragged-right]
907 \markup \box \box HELLO
910 Ahora, consideramos que es preferible tener más separación entre el
911 texto y los rectángulos. Según la documentación de @code{\box}, esta
912 instrucción usa una propiedad @code{box-padding}, cuyo valor
913 predeterminado es 0.2. La documentación también menciona cómo
914 sobreescribir este valor:
916 @lilypond[quote,verbatim,ragged-right]
917 \markup \box \override #'(box-padding . 0.6) \box A
920 Después, el relleno o separación entre los dos rectángulos nos parece
921 muy pequeño, así que lo vamos a sobreescribir también:
923 @lilypond[quote,verbatim,ragged-right]
924 \markup \override #'(box-padding . 0.4) \box
925 \override #'(box-padding . 0.6) \box A
928 Repetir esta extensa instrucción de marcado una y otra vez sería un
929 quebradero de cabeza. Aquí es donde se necesita una instrucción de
930 marcado. Así pues, escribimos una instrucción de marcado
931 @code{double-box}, que toma un argumento (el texto). Dibuja los dos
932 rectángulos y añade una separación.
935 #(define-markup-command (double-box layout props text) (markup?)
936 "Trazar un rectángulo doble rodeando el texto."
937 (interpret-markup layout props
938 #@{\markup \override #'(box-padding . 0.4) \box
939 \override #'(box-padding . 0.6) \box @{ #text @}#@}))
945 #(define-markup-command (double-box layout props text) (markup?)
946 "Trazar un rectángulo doble rodeando el texto."
947 (interpret-markup layout props
948 (markup #:override '(box-padding . 0.4) #:box
949 #:override '(box-padding . 0.6) #:box text)))
952 @code{text} es el nombre del argumento de la instrucción, y
953 @code{markup?} es el tipo: lo identifica como un elemento de marcado.
954 La función @code{interpret-markup} se usa en casi todas las
955 instrucciones de marcado: construye un sello, usando @code{layout},
956 @code{props}, y un elemento de marcado. En el segundo caso, la marca
957 se construye usando el macro de Scheme @code{markup}, véase
958 @ref{Construcción de elementos de marcado en Scheme}. La
959 transformación de una expresión @code{\markup} en una expresión de
960 marcado de Scheme es directa.
962 La instrucción nueva se puede usar como sigue:
965 \markup \double-box A
968 Sería buen hacer que la instrucción @code{double-box} fuera
969 personalizable: aquí, los valores de relleno @code{box-padding} son
970 fijos, y no se pueden cambiar por parte del usuario. Además, sería
971 mejor distinguir la separación entre los dos rectángulos, del relleno
972 entre el rectángulo interno y el texto. Así pues, introducimos una
973 nueva propiedad, @code{inter-box-padding}, para el relleno entre los
974 rectángulos. El @code{box-padding} se usará para el relleno interno.
975 Ahora el código nuevo es como se ve a continuación:
978 #(define-markup-command (double-box layout props text) (markup?)
979 #:properties ((inter-box-padding 0.4)
981 "Trazar un rectángulo doble rodeando el texto."
982 (interpret-markup layout props
983 #@{\markup \override #`(box-padding . ,inter-box-padding) \box
984 \override #`(box-padding . ,box-padding) \box
988 De nuevo, la versión equivalente que utiliza la macro de marcado sería:
991 #(define-markup-command (double-box layout props text) (markup?)
992 #:properties ((inter-box-padding 0.4)
994 "Trazar un rectángulo doble rodeando el texto."
995 (interpret-markup layout props
996 (markup #:override `(box-padding . ,inter-box-padding) #:box
997 #:override `(box-padding . ,box-padding) #:box text)))
1000 Aquí, la palabra clave @code{#:properties} se usa de manera que las
1001 propiedades @code{inter-box-padding} y @code{box-padding} se leen a
1002 partir del argumento @code{props}, y se les proporcionan unos valores
1003 predeterminados si las propiedades no están definidas.
1005 Después estos valores se usan para sobreescribir las propiedades
1006 @code{box-padding} usadas por las dos instrucciones @code{\box}.
1007 Observe el apóstrofo invertido y la coma en el argumento de
1008 @code{\override}: nos permiten introducir un valor de variable dentro
1009 de una expresión literal.
1011 Ahora, la instrucción se puede usar dentro de un elemento de marcado,
1012 y el relleno de los rectángulos se puede personalizar:
1014 @lilypond[quote,verbatim,ragged-right]
1015 #(define-markup-command (double-box layout props text) (markup?)
1016 #:properties ((inter-box-padding 0.4)
1018 "Draw a double box around text."
1019 (interpret-markup layout props
1020 #{\markup \override #`(box-padding . ,inter-box-padding) \box
1021 \override #`(box-padding . ,box-padding) \box
1024 \markup \double-box A
1025 \markup \override #'(inter-box-padding . 0.8) \double-box A
1026 \markup \override #'(box-padding . 1.0) \double-box A
1030 @node Adaptación de instrucciones incorporadas
1031 @unnumberedsubsubsec Adaptación de instrucciones incorporadas
1032 @translationof Adapting builtin commands
1034 Una buena manera de comenzar a escribir una instrucción de marcado
1035 nueva, es seguir el ejemplo de otra instrucción ya incorporada. Casi
1036 todas las instrucciones de marcado que están incorporadas en LilyPond
1037 se pueden encontrar en el archivo
1038 @file{scm/define-markup-commands.scm}.
1040 Por ejemplo, querríamos adaptar la instrucción @code{\draw-line}, para
1041 que trace una línea doble. La instrucción @code{\draw-line} está
1042 definida como sigue (se han suprimido los comentarios de
1046 (define-markup-command (draw-line layout props dest)
1049 #:properties ((thickness 1))
1050 "@dots{}documentación@dots{}"
1051 (let ((th (* (ly:output-def-lookup layout 'line-thickness)
1055 (make-line-stencil th 0 0 x y)))
1058 Para definir una instrucción nueva basada en otra existente, copie la
1059 definición y cámbiele el nombre. La palabra clave @code{#:category}
1060 se puede eliminar sin miedo, pues sólo se utiliza para generar
1061 documentación de LilyPond, y no tiene ninguna utilidad para las
1062 instrucciones de marcado definidas por el usuario.
1065 (define-markup-command (draw-double-line layout props dest)
1067 #:properties ((thickness 1))
1068 "@dots{}documentación@dots{}"
1069 (let ((th (* (ly:output-def-lookup layout 'line-thickness)
1073 (make-line-stencil th 0 0 x y)))
1076 A continuación se añade una propiedad para establecer la separación
1077 entre las dos líneas, llamada @code{line-gap}, con un valor
1078 predeterminado de p.ej. 0.6:
1081 (define-markup-command (draw-double-line layout props dest)
1083 #:properties ((thickness 1)
1085 "@dots{}documentación@dots{}"
1089 Finalmente, se añade el código para trazar las dos líneas. Se usan
1090 dos llamadas a @code{make-line-stencil} para trazar las líneas, y los
1091 sellos resultantes se combinan usando @code{ly:stencil-add}:
1093 @lilypond[quote,verbatim,ragged-right]
1094 #(define-markup-command (my-draw-line layout props dest)
1096 #:properties ((thickness 1)
1099 (let* ((th (* (ly:output-def-lookup layout 'line-thickness)
1103 (w (/ line-gap 2.0))
1104 (x (cond ((= dx 0) w)
1106 (else (/ w (sqrt (+ 1 (* (/ dx dy) (/ dx dy))))))))
1107 (y (* (if (< (* dx dy) 0) 1 -1)
1110 (else (/ w (sqrt (+ 1 (* (/ dy dx) (/ dy dx))))))))))
1111 (ly:stencil-add (make-line-stencil th x y (+ dx x) (+ dy y))
1112 (make-line-stencil th (- x) (- y) (- dx x) (- dy y)))))
1114 \markup \my-draw-line #'(4 . 3)
1115 \markup \override #'(line-gap . 1.2) \my-draw-line #'(4 . 3)
1119 @node Definición de nuevas instrucciones de lista de marcado
1120 @subsection Definición de nuevas instrucciones de lista de marcado
1121 @translationof New markup list command definition
1123 Las instrucciones de listas de marcado se definen con el macro de
1124 Scheme @code{define-markup-list-command}, que es similar al macro
1125 @code{define-markup-command} descrito en @ref{Definición de una
1126 instrucción de marcado nueva}, excepto que donde éste devuelve un
1127 sello único, aquél devuelve una lista de sellos.
1129 En el siguiente ejemplo se define una instrucción de lista de marcado
1130 @code{\paragraph}, que devuelve una lista de líneas justificadas,
1131 estando la primera de ellas sangrada. La anchura del sangrado se toma
1132 del argumento @code{props}.
1135 #(define-markup-list-command (paragraph layout props args) (markup-list?)
1136 #:properties ((par-indent 2))
1137 (interpret-markup-list layout props
1138 #@{\markuplist \justified-lines @{ \hspace #par-indent #args @} #@}))
1142 La versión que usa solamente Scheme es más compleja:
1144 #(define-markup-list-command (paragraph layout props args) (markup-list?)
1145 #:properties ((par-indent 2))
1146 (interpret-markup-list layout props
1147 (make-justified-lines-markup-list (cons (make-hspace-markup par-indent)
1151 Aparte de los argumentos usuales @code{layout} y @code{props}, la
1152 instrucción de lista de marcados @code{paragraph} toma un argumento de
1153 lista de marcados, llamado @code{args}. El predicado para listas de
1154 marcados es @code{markup-list?}.
1156 En primer lugar, la función toma el ancho del sangrado, una propiedad
1157 llamada aquí @code{par-indent}, de la lista de propiedades
1158 @code{props}. Si no se encuentra la propiedad, el valor
1159 predeterminado es @code{2}. Después, se hace una lista de líneas
1160 justificadas usando la instrucción incorporada de lista de marcados
1161 @code{\justified-lines}, que está relacionada con la función
1162 @code{make-justified-lines-markup-list}. Se añade un espacio
1163 horizontal al principio usando @code{\hspace} (o la función
1164 @code{make-hspace-markup}). Finalmente, la lista de marcados se
1165 interpreta usando la función @code{interpret-markup-list}.
1167 Esta nueva instrucción de lista de marcados se puede usar como sigue:
1172 El arte de la tipografía musical se llama \italic @{grabado (en plancha).@}
1173 El término deriva del proceso tradicional de impresión de música.
1174 hace sólo algunas décadas, las partituras se hacían cortando y estampando
1175 la música en una plancha de zinc o lata en una imagen invertida.
1177 \override-lines #'(par-indent . 4) \paragraph @{
1178 La plancha se tenía que entintar, y las depresiones causadas por los cortes
1179 y estampados retienen la tinta. Se formaba una imagen presionando el papel
1180 contra la plancha. El estampado y cortado se hacía completamente
1187 @node Contextos para programadores
1188 @section Contextos para programadores
1189 @translationof Contexts for programmers
1192 * Evaluación de contextos::
1193 * Ejecutar una función sobre todos los objetos de la presentación::
1196 @node Evaluación de contextos
1197 @subsection Evaluación de contextos
1198 @translationof Context evaluation
1200 @cindex código, llamadas durante la interpretación
1201 @funindex \applyContext
1203 Se pueden modificar los contextos durante la interpretación con código
1204 de Scheme. La sintaxis para esto es
1207 \applyContext @var{función}
1210 @code{@var{función}} debe ser una función de Scheme que toma un único
1211 argumento, que es el contexto al que aplicarla. El código siguiente
1212 imprime el número del compás actual sobre la salida estándar durante
1218 (format #t "\nSe nos ha llamado en el compás número ~a.\n"
1219 (ly:context-property x 'currentBarNumber)))
1223 @node Ejecutar una función sobre todos los objetos de la presentación
1224 @subsection Ejecutar una función sobre todos los objetos de la presentación
1225 @translationof Running a function on all layout objects
1227 @cindex código, llamar sobre objetos de presentación
1228 @funindex \applyOutput
1231 La manera más versátil de realizar el ajuste fino de un objeto es
1232 @code{\applyOutput}, que
1233 funciona insertando un evento dentro del contexto especificado
1234 (@rinternals{ApplyOutputEvent}). Su sintaxis es
1237 \applyOutput @var{Contexto} @var{proc}
1241 donde @code{@var{proc}} es una función de Scheme que toma tres argumentos.
1243 Al interpretarse, la función @code{@var{proc}} se llama para cada objeto de
1244 presentación que se encuentra en el contexto @code{@var{Contexto}}
1245 en el tiempo actual, con los siguientes argumentos:
1248 @item el propio objeto de presentación,
1249 @item el contexto en que se creó el objeto de presentación, y
1250 @item el contexto en que se procesa @code{\applyOutput}.
1254 Además, la causa del objeto de presentación, es decir el objeto o
1255 expresión musical que es responsable de haberlo creado, está en la
1256 propiedad @code{cause} del objeto. Por ejemplo, para la cabeza de una
1257 nota, éste es un evento @rinternals{NoteHead}, y para un objeto
1258 plica, éste es un objeto @rinternals{Stem}.
1260 He aquí una función que usar para @code{\applyOutput}; borra las
1261 cabezas de las notas que están sobre la línea central y junto a ella:
1263 @lilypond[quote,verbatim,ragged-right]
1264 #(define (blanker grob grob-origin context)
1265 (if (and (memq 'note-head-interface (ly:grob-interfaces grob))
1266 (< (abs (ly:grob-property grob 'staff-position)) 2))
1267 (set! (ly:grob-property grob 'transparent) #t)))
1270 a'4 e8 <<\applyOutput #'Voice #blanker a c d>> b2
1274 Para que @var{función} se interprete en los niveles de @code{Score} o de @code{Staff}
1275 utilice estas formas:
1278 \applyOutput #'Score #@var{función}
1279 \applyOutput #'Staff #@var{función}
1283 @node Funciones de callback
1284 @section Funciones de callback
1285 @translationof Callback functions
1287 Las propiedades (como @code{thickness} (grosor), @code{direction}
1288 (dirección), etc.) se pueden establecer a valores fijos con \override,
1292 \override Stem.thickness = #2.0
1295 Las propiedades pueden fijarse también a un procedimiento de Scheme,
1297 @lilypond[fragment,verbatim,quote,relative=2]
1298 \override Stem.thickness = #(lambda (grob)
1299 (if (= UP (ly:grob-property grob 'direction))
1306 En este caso, el procedimiento se ejecuta tan pronto como el valor de
1307 la propiedad se reclama durante el proceso de formateo.
1309 Casi todo el motor de tipografiado está manejado por estos
1310 @emph{callbacks}. Entre las propiedades que usan normalmente
1311 @emph{callbacks} están
1315 La rutina de impresión, que construye un dibujo para el símbolo
1317 La rutina que establece la posición horizontal
1319 La rutina que calcula la anchura de un objeto
1322 El procedimiento siempre toma un argumento único, que es el grob (el
1325 Si se deben llamar rutinas con varios argumentos, el grob actual se
1326 puede insertar con una cerradura de grob. He aquí un ajuste
1327 procedente de @code{AccidentalSuggestion},
1331 ,(ly:make-simple-closure
1333 ,(ly:make-simple-closure
1334 (list ly:self-alignment-interface::centered-on-x-parent))
1335 ,(ly:make-simple-closure
1336 (list ly:self-alignment-interface::x-aligned-on-self)))))
1340 En este ejemplo, tanto
1341 @code{ly:self-alignment-interface::x-aligned-on-self} como
1342 @code{ly:self-alignment-interface::centered-on-x-parent} se llaman con
1343 el grob como argumento. El resultado se añade con la función
1344 @code{+}. Para asegurar que esta adición se ejecuta adecuadamente,
1345 todo ello se encierra dentro de @code{ly:make-simple-closure}.
1347 De hecho, usar un solo procedimiento como valor de una propiedad
1351 (ly:make-simple-closure (ly:make-simple-closure (list @var{proc})))
1355 El @code{ly:make-simple-closure} interior aporta el grob como
1356 argumento de @var{proc}, el exterior asegura que el resultado de la
1357 función es lo que se devuelve, en lugar del objeto
1358 @code{simple-closure}.
1360 Desde dentro de un callback, el método más fácil para evaluar un
1361 elemento de marcado es usar grob-interpret-markup. Por ejemplo:
1364 mi-callback = #(lambda (grob)
1365 (grob-interpret-markup grob (markup "fulanito")))
1369 @node Código de Scheme en línea
1370 @section Código de Scheme en línea
1371 @translationof Inline Scheme code
1373 La principal desventaja de @code{\tweak} es su inflexibilidad
1374 sintáctica. Por ejemplo, lo siguiente produce un error de sintaxis.
1377 F = \tweak font-size #-3 -\flageolet
1385 Usando Scheme, se puede dar un rodeo a este problema. La ruta hacia
1386 el resultado se da en @ref{Añadir articulaciones a las notas
1387 (ejemplo)}, especialmente cómo usar @code{\displayMusic} como guía de
1391 F = #(let ((m (make-music 'ArticulationEvent
1392 'articulation-type "flageolet")))
1393 (set! (ly:music-property m 'tweaks)
1394 (acons 'font-size -3
1395 (ly:music-property m 'tweaks)))
1404 Aquí, las propiedades @code{tweaks} del objeto flageolet @code{m}
1405 (creado con @code{make-music}) se extraen con
1406 @code{ly:music-property}, se antepone un nuevo par clave-valor para
1407 cambiar el tamaño de la tipografía a la lista de propiedades con la
1408 función de Scheme @code{acons}, y finalmente el resultado se escribe
1409 de nuevo con @code{set!}. El último elemento del bloque @code{let} es
1410 el valor de retorno, el propio @code{m}.
1413 @node Trucos difíciles
1414 @section Trucos difíciles
1415 @translationof Difficult tweaks
1417 Hay un cierto número de tipos de ajustes difíciles.
1423 Un tipo de ajuste difícil es la apariencia de los objetos de
1424 extensión, como las ligaduras de expresión y de unión. Inicialmente,
1425 sólo se crea uno de estos objetos, y pueden ajustarse con el mecanismo
1426 normal. Sin embargo, en ciertos casos los objetos extensores cruzan
1427 los saltos de línea. Si esto ocurre, estos objetos se clonan. Se
1428 crea un objeto distinto por cada sistema en que se encuentra. Éstos
1429 son clones del objeto original y heredan todas sus propiedades,
1430 incluidos los @code{\override}s.
1432 En otras palabras, un @code{\override} siempre afecta a todas las
1433 piezas de un objeto de extensión fragmentado. Para cambiar sólo una
1434 parte de un extensor en el salto de línea, es necesario inmiscuirse en
1435 el proceso de formateado. El @emph{callback}
1436 @code{after-line-breaking} contiene el procedimiento Scheme que se
1437 llama después de que se han determinado los saltos de línea, y los
1438 objetos de presentación han sido divididos sobre los distintos
1441 En el ejemplo siguiente, definimos un procedimiento
1442 @code{my-callback}. Este procedimiento
1446 determina si hemos sido divididos por los saltos de línea
1448 en caso afirmativo, reúne todos los objetos divididos
1450 comprueba si somos el último de los objetos divididos
1452 en caso afirmativo, establece @code{extra-offset}.
1455 Este procedimiento se instala en @rinternals{Tie} (ligadura de unión),
1456 de forma que la última parte de la ligadura dividida se traslada hacia
1459 @lilypond[quote,verbatim,ragged-right]
1460 #(define (my-callback grob)
1462 ;; have we been split?
1463 (orig (ly:grob-original grob))
1465 ;; if yes, get the split pieces (our siblings)
1466 (siblings (if (ly:grob? orig)
1467 (ly:spanner-broken-into orig)
1470 (if (and (>= (length siblings) 2)
1471 (eq? (car (last-pair siblings)) grob))
1472 (ly:grob-set-property! grob 'extra-offset '(-2 . 5)))))
1475 \override Tie.after-line-breaking =
1483 Al aplicar este truco, la nueva función de callback
1484 @code{after-line-breaking} también debe llamar a la antigua,
1485 si existe este valor predeterminado. Por ejemplo, si se usa con
1486 @code{Hairpin}, se debe llamar también a
1487 @code{ly:spanner::kill-zero-spanned-time}.
1490 @item Algunos objetos no se pueden cambiar con @code{\override} por
1491 razones técnicas. Son ejemplos @code{NonMusicalPaperColumn} y
1492 @code{PaperColumn}. Se pueden cambiar con la función
1493 @code{\overrideProperty} que funciona de forma similar a @code{\once
1494 \override}, pero usa una sintaxis distinta.
1498 Score.NonMusicalPaperColumn % Nombre del grob
1499 . line-break-system-details % Nombre de la propiedad
1500 . next-padding % Nombre de la subpropiedad, opcional
1504 Observe, sin embargo, que @code{\override}, aplicado a
1505 @code{NonMusicalPaperColumn} y a @code{PaperColumn}, aún funciona
1506 como se espera dentro de los bloques @code{\context}.
1511 @node Interfaces de Scheme de LilyPond
1512 @chapter Interfaces de Scheme de LilyPond
1513 @translationof LilyPond Scheme interfaces
1515 Este capítulo cubre las diversas herramientas proporcionadas por
1516 LilyPond como ayuda a los programadores de Scheme a extraer e
1517 introducir información de los flujos musicales.
1519 HACER @c TODO -- figure out what goes in here and how to organize it