lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Does \balloonText only work inside chords?


From: David Kastrup
Subject: Re: Does \balloonText only work inside chords?
Date: Mon, 18 Jun 2018 14:17:55 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Urs Liska <address@hidden> writes:

> Am 18.06.2018 um 11:56 schrieb Urs Liska:
>> <... snip discussion of documentation...>
>>
>> 2) Additionally, it seems that \balloonText only works within
>> chords, which seems sort-of strange to me
>>
>> Modified from an example in NR 1.7.2:
>>
>> \version "2.19.80"
>>
>> \new Voice \with {
>>    \consists "Balloon_engraver"
>> }
>> \relative {
>>   \displayMusic { <c' -\balloonText #'(-2 . -2) \markup { "I'm a note head" 
>> } >}
>>   \displayMusic { c' -\balloonText #'(-2 . -2) \markup { "I'm a note head" }}
>> }
>>
>
> After David's comment I wrote a music-function modeled after \footnote:
>
> myBalloon =
> #(define-music-function (offset text mus)
>    (number-pair? markup? ly:music?)
>    (let ((ann (make-music
>                'AnnotateOutputEvent
>                'X-offset (car offset)
>                'Y-offset (cdr offset)
>                'text (markup #:line (#:simple text)))))
>      (ly:music-set-property! mus 'articulations (list ann))
>      mus))
>
> This allows the following expressions:
>
>     <c' \myBalloon #'(2 . -2) "Hey" c''> % annotate the c'' *after* \myBalloon
>     c' -\myBalloon #'(2 . -2) "Hey" -!   % this properly annotates the 
> articulation
>
> but (as said in my initial post) it is not possible to annotate single
> notes outside of chords:
>
>     \myBalloon #'(2 . -2) "Hey" c'
>     % like the "official" c' -\balloonText #'(-2 . -2) \markup { "Hey" }
>
> errors out with:
>
> /home/uliska/software/lilypond/releases/2.19.80/usr/share/lilypond/current/scm/lily.scmBacktrace:
> In unknown file:
>    ?:  0* [lilypond-main ("/home/uliska/Schreibtisch/unknown.ly")]
> In 
> /home/uliska/software/lilypond/releases/2.19.80/usr/share/lilypond/current/scm/lily.scm:
> 1025:  1* (let* ((failed #)) (if (ly:get-option #) (begin #)) ...)
> 1025:  2* [lilypond-all ("/home/uliska/Schreibtisch/unknown.ly")]
> 1038:  3  (let* ((failed #) (separate-logs #) (ping-log #) ...) (gc) ...)
> 1050:  4* [for-each #<procedure #f (x)> 
> ("/home/uliska/Schreibtisch/unknown.ly")]
> In unknown file:
>    ?:  5* [#<procedure #f (x)> "/home/uliska/Schreibtisch/unknown.ly"]
> In 
> /home/uliska/software/lilypond/releases/2.19.80/usr/share/lilypond/current/scm/lily.scm:
> 1052:  6* (let* (# # #) (if separate-logs #) (if ping-log #) ...)
> 1063:  7* [lilypond-file #<procedure #f #> 
> "/home/uliska/Schreibtisch/unknown.ly"]
> 1098:  8  [catch ly-file-failed #<procedure #f {()}> #<procedure #f (x . 
> args)>]
> In unknown file:
>    ?:  9* [#<procedure #f {()}>]
> In 
> /home/uliska/software/lilypond/releases/2.19.80/usr/share/lilypond/current/scm/lily.scm:
> 1099: 10* [ly:parse-file "/home/uliska/Schreibtisch/unknown.ly"]
> In 
> /home/uliska/software/lilypond/releases/2.19.80/usr/share/lilypond/current/ly/init.ly:
>   56: 11* (let* ((book-handler #)) (cond (# #) (# #)))
>   59: 12  (cond (# #) (# #))
> In 
> /home/uliska/software/lilypond/releases/2.19.80/usr/share/lilypond/current/scm/lily-library.scm:
>     ...
>  243: 13  [ly:book-process #<Book> #< Output_def> #< Output_def> "unknown"]
> In unknown file:
>    ?: 14* [# #]
>    ?: 15* [# # #]
>    ?: 16* [# # # #]
>
> ERROR: In procedure symbol->string:
> ERROR: Wrong type argument in position 1 (expecting symbol): ()
> Exited with return code 1.
>
> Any idea what is wrong here?

The engravers do things differently.  You have to adapt more than just
the Scheme code.

> And would it be useful to turn my function in a proposal?

Not independently of the C++ code I should think.

> It does seem to work like footnotes, and while the chord issue isn't
> sorted out I think this is at a completely different location and
> independent of such a change.

I have not looked at the details for years but this sounds optimistic.
I think that some more C++ and Scheme work is required, and then loads
of convert-ly and documentation rewrite work.  It does help that the
documentation currently is terrible, so it's comparatively easy to raise
the bar from where it is.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]