Re: skylines and custom-code

[Jean Abou Samra]

Le 03/04/2021 à 17:28, Thomas Morley a écrit :

> Hi,
>
> please consider the code below.
>
> \version "2.22.0"
>
> #(ly:set-option 'debug-skylines #t)
>
> {
>   \override NoteHead.no-ledgers = ##t
>   %\override NoteHead.stencil = #point-stencil
>   \override Stem.stencil =
>     #(lambda (grob)
>       (for-each
>         (lambda (nh) (ly:grob-translate-axis! nh -6 Y))
>         (ly:grob-array->list
>           (ly:grob-object (ly:grob-parent grob X) 'note-heads)))
>       (ly:stem::print grob))
>   b'''8
>   b'''8.
> }
>
> For some graphical notation I need to move notes (i.e. at least
> NoteHead, Stem, Flag) freely in Y-axis direction.
> Using ly:grob-translate-axis! seemed to be nice for this pupose,
> because while moving the NoteHead the mentioned other Grobs follow.
>
> Alas, enabling 'debug-skylines shows a problem: the skyline obviously
> still sees the old grob-positions.
>
> How to avoid, circumvent, correct?
>
> Furthermore, why there's no problem for dotted notes?
>
>
> Thanks,
>   Harm
>

Hi Harm,

Skylines are generally computed early in the typesetting process.  I've never know what the default method for computing them in the absence of a vertical-skylines callback is, but at least some grobs in define-grobs.scm have grob::always-vertical-skylines-from-stencil in vertical-skylines, and that is an pure-unpure container, so there is a part computed before line breaking. I think this serves in the page breaking algorithms, to determine how many systems can be put on the page. If you call ly:grob-translate-axis! in a stencil callback, it might come after the skylines have been built, and cached, and actively used. About the dot: I added some debugging messages to see what's going on.

\version "2.23.2" #(ly:set-option 'debug-skylines #t) {   \override NoteHead.no-ledgers = ##t   %\override NoteHead.stencil = #point-stencil   \override Stem.stencil =     #(lambda (grob)        (ly:message "Stem callback, duration of note: ~s"                    (ly:event-property                      (event-cause                        (first                          (ly:grob-array->list                            (ly:grob-object grob 'note-heads))))                      'duration))       (for-each         (lambda (nh) (ly:grob-translate-axis! nh -6 Y))         (ly:grob-array->list           (ly:grob-object (ly:grob-parent grob X) 'note-heads)))       (ly:stem::print grob))   b'''8   b''''8. }

Output is:

Preprocessing graphical objects...

Stem callback, duration of note: #<Duration 8. >

Finding the ideal number of pages...

Fitting music on 1 page...

Drawing systems...

Stem callback, duration of note: #<Duration 8 > This looks like something in Dots or DotColumn callbacks is triggering Stem.stencil earlier. I have no idea what exactly. This is why side effects in callbacks are a bit dangerous. They make the process depend on a certain order in computing the properties. Does it fit your use case just to write a pure-unpure callback for NoteHead.Y-offset? For example (an idea stolen from Valentin):

\version "2.23.2" % #(ly:set-option 'debug-skylines #t) { \time 9/8 \override NoteHead.no-ledgers = ##t \override NoteHead.Y-offset = #(ly:make-unpure-pure-container (lambda (note-head) (let* ((note-column (ly:grob-parent note-head X)) (paper-column (ly:grob-parent note-column X)) (moment (ly:grob-property paper-column 'when)) (main-part (ly:moment-main moment))) (* 3 (+ (sin main-part) (sin (+ 1 (* main-part 2)))))))) \repeat unfold 30 c'4. } Not sure if the unpure-pure container is actually needed here. I think so. At least, the default for NoteHead.Y-offset (staff-symbol-referencer::callback) is a pure-unpure container, so it should be safe as long as your function is pure.

Hope that helps, Jean