> > Regardless, I will leave you with my final contribution of a "cleaned > up" version with some logic and usage updates. In particular, I > reordered the arguments to enable default values for the alignments. > And the main refactoring uses a different approach to assembling the > markup, which makes handling the parentheses simpler. >
Wow, thanks a million, Aaron! This works perfectly! This Scheme crash course is leaving me with much to chew for the next few weeks ;-) and your script is a great contribution! Now, it is as if all > you need is a normal MetronomeMark aligned to the end of a TextSpanner. > After all, reusing is preferred to reinventing. > That's right. It sounds simple but it isn't. There's an open issue about the subject since at least 2013 https://code.google.com/archive/p/lilypond/issues/3176. There are two unsatisfactory problems for usability involved from my point of view. One is the impossibility to use proper markup syntax for text spanners. I opened a thread about it in July https://lists.gnu.org/archive/html/lilypond-user/2020-07/msg00263.html. Right now there is what I consider an abuse of \overrides. An \override should be used to be able to change "sensible" defaults. In the case of text spanners, the default has no musical use: a dashed line with no text on either side. The syntax of a text spanner has the serious omission of starting something without user input (\startTextSpan starts what? The user should have an "interface" to give an initial input. This interface is what I call \markupSpan in my feature request, a function that I'm also implementing at least for personal use for the moment). That an \override has to be used for making a basic input (and mostly for actually overriding a property) is unsatisfactory. The second issue is the mentioned 2013 issue. Lilypond lacks the possibility of using text spanners not only with a \tempo syntax (which thanks to your script is very well solved now!), something that makes the "music" in the code more legible (because there is proper markup of musical events) but also to format the whole thing as a \tempo marking in the score (tempo indications are not attached to the staff but to the system, and horizontally metronome marks are not attached to the first note of the measure but to the time signature above which they are centered, that's why I included \halign properties in the script as workaround). So while you could continue to develop the function above, perhaps time > would be better spent solving the underlying issues that necessitated > creating this function in the first place. Though, that discussion > would likely merit its own thread. > It would be awesome if this thread is the seed for waters to start moving to close the 2013 issue and perhaps to have a proper markup syntax for allowing user input for text spanners (\markupSpan, \textSpan or whatever is adopted, leaving overrides for actual properties). Both issues already have their own threads in the archive. Best regards, Martín. Am Fr., 18. Sept. 2020 um 16:26 Uhr schrieb Aaron Hill < lilyp...@hillvisions.com>: > On 2020-09-18 4:40 am, Martín Rincón Botero wrote: > > Thank you very much, Aaron! The \markup \null construction is something > > that I will have to study carefully in the next few days to fully grasp > > it. > > I made some adjustments to the formatting, so that it matches the > > default > > \tempo formatting of Lilypond, especially when using a tempo range > > (Lilypond uses – instead of -, and leaves a space before and after the > > hyphen, so your added \concat is not required here ;-)), and I made all > > \tempo text bold by default (as Lilypond does). However, your example > > made > > me compare it with Lilypond's formatting and there's still one issue > > even > > after fixing the other small details: When the user writes \tempo > > "Adagio" > > 4 = 70, he expects the tempo unit and metronome count in parenthesis > > after > > the given text. Here I'm absolutely limited by my Scheme ignorance on > > how > > to achieve that (somehow combining several conditions and adding > > \markup > > {#text \concat { "(" #tempo-unit } = \concat { #metronome-count ")" } > > ?). > > Looking at the internal format-metronome-markup function, it uses half > spaces (U+2009) and an en dash (U+2013). > > Regardless, I will leave you with my final contribution of a "cleaned > up" version with some logic and usage updates. In particular, I > reordered the arguments to enable default values for the alignments. > And the main refactoring uses a different approach to assembling the > markup, which makes handling the parentheses simpler. > > %%%% > \version "2.20.0" > > tempoTextSpan = > #(define-music-function > (left-halign left-text right-halign tempo) > ((number? LEFT) markup? (number? LEFT) ly:music?) > > (define (tempo-property prop) > (if (ly:prob? tempo) > (ly:prob-property tempo prop #f))) > > ;; Verify tempo argument contains one tempo-change-event. > (let ((events (extract-typed-music tempo 'tempo-change-event))) > (if (eq? 1 (length events)) > (set! tempo (first events)) > (begin > (ly:music-error tempo > "Argument must specify a single \\tempo indication.") > (set! tempo #f)))) > > (let ((tempo-text (tempo-property 'text)) > (tempo-unit (tempo-property 'tempo-unit)) > (metronome-count (tempo-property 'metronome-count)) > (tempo-markup #f)) > > (if (ly:duration? tempo-unit) > (set! tempo-markup > #{ > \markup { > \general-align #Y #DOWN > \smaller > \note #(ly:duration->string tempo-unit) #UP > = > #(cond > ((number-pair? metronome-count) > #{ > \markup \concat { > #(format #f "~d" (car metronome-count)) > \char ##x2009 \char ##x2013 \char ##x2009 > #(format #f "~d" (cdr metronome-count)) > } > #}) > ((number? metronome-count) > #{ \markup #(format #f "~d" metronome-count) #}) > (else (make-null-markup))) > } > #})) > (if (markup? tempo-text) > (set! tempo-markup > #{ > \markup { > \bold #tempo-text > #(if (markup? tempo-markup) > #{ \markup \concat { ( #tempo-markup ) } #} > (make-null-markup)) > } > #})) > > #{ > \once { > \override TextSpanner.bound-details.left-broken.text = ##f > \override TextSpanner.bound-details.right-broken.text = ##f > \override TextSpanner.bound-details.left.text = > \markup \abs-fontsize #11 > \halign #left-halign #left-text > \override TextSpanner.bound-details.right.text = > \markup \abs-fontsize #11 \normal-text > \halign #right-halign #tempo-markup > } > #})) > > { > \tempoTextSpan "accel." #RIGHT \tempo 2 = 50-55 > g'4\startTextSpan 4 4 4 | 2 2 | 1\stopTextSpan | R1 > \tempoTextSpan #RIGHT "rall." #CENTER \tempo "Adagio" 4 = 60 > g'4\startTextSpan 4 4 4 | 2 2 | 1\stopTextSpan | R1 > \tempoTextSpan "rit." #-0.5 \tempo \markup \circle \bold "!" > g'4\startTextSpan 4 4 4 | 2 2 | 1\stopTextSpan \bar "|." > } > > %% Uncomment to test argument validation. > % \tempoTextSpan "missing \\tempo" { } > % \tempoTextSpan "too many \\tempos" { \tempo "" \tempo "" } > %%%% > > > > Oh! Right! Then I guess one solution would be to name the function > > \tempoSpan instead, with a "dummy" variable (for the sake of syntax) > > startTempoSpan = \startTextSpan and a variable stopTempoSpan, that > > would > > have to call the previous obtained values of tempoSpan (that I can't > > re-use > > because they're a markup and not a number anymore? Or because I don't > > know > > how to call information obtained in other variables? Or both? GUILLE > > complains of an Unbound variable: tempo-unit and Unbound variable: > > metronome-count) and would add something like stopTempoSpan = > > \stopTextSpan > > \once \omit Score.MetronomeMark \tempo #tempo-unit = #metronome-count. > > You could use context properties to persist the relevant information; > or, if you were feeling more adventurous, you could build a custom > engraver/performer to do the work. > > But if I can be honest, this approach is starting to feel awkward and > potentially circuitous. Initially, I had no idea what you intended to > do with the information from the \tempo command. Now, it is as if all > you need is a normal MetronomeMark aligned to the end of a TextSpanner. > After all, reusing is preferred to reinventing. > > So while you could continue to develop the function above, perhaps time > would be better spent solving the underlying issues that necessitated > creating this function in the first place. Though, that discussion > would likely merit its own thread. > > > -- Aaron Hill -- www.martinrinconbotero.com
