Lukas-Fabian Moser <[email protected]> writes:
>> Jean Abou Samra knew how to fix that behaviour of arpeggios, so
>> here's a (I hope) working solution:
>
> It seems we can continue this game of "LilyPond experts explain how to
> do things and I only have to post the resulting, ever simpler
> examples" for some time. :-)
>
> Harm pointed out in
> https://gitlab.com/lilypond/lilypond/-/issues/6193#note_701181244 that
> it suffices to do:
>
> \version "2.22"
>
> arpeggioUpDown = {
> \override Arpeggio.stencil =
> #(lambda (grob)
> (let ((one #f) (two #f) (combined-stencil #f))
> (ly:grob-set-property! grob 'arpeggio-direction UP)
> (set! one (ly:arpeggio::print grob))
> (ly:grob-set-property! grob 'arpeggio-direction DOWN)
> (set! two (ly:arpeggio::print grob))
> (set! combined-stencil
> (ly:stencil-add
> one
> (ly:stencil-translate-axis two 1.25 X)))
> (ly:grob-set-property!
> grob 'X-extent
> (ly:stencil-extent combined-stencil X))
> (ly:pointer-group-interface::add-grob
> (ly:grob-parent grob X) 'elements grob)
> combined-stencil))
> \override Arpeggio.direction = #RIGHT
> }
set! is very unidiomatic Scheme. You could use
(let* ((one (begin (ly:grob-set-property! ...) (ly:arpeggio::print grob)))
((two ...
but I don't even know whether there is a guarantee that
ly:arpeggio::print is happy with the grob being modified after the call
and before the stencil is getting used. Looking at the C++ code, that
appears to be the case. Maybe giving ly:arpeggio::print an optional
overriding direction argument could be cleaner? It doesn't help with
creating user-level code for current LilyPond versions, of course.
--
David Kastrup
