Re: skylines and custom-code

[Thomas Morley]

Am So., 4. Apr. 2021 um 01:25 Uhr schrieb Jean Abou Samra <jean@abou-samra.fr>:
>
> 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

Hi Jean,

thanks for your reply, though the situation is more complex than the
initial minimal. Consider the following:

{ b'4\glissando 4 4 4 2 b'' }

The plan is to print a glissando from b' to b'' and at intermediate
NoteColumns print a Stem starting at the glissando line, i.e. the
result will be a stemmed Glissando.
(1) Obviously I need the intersection points of the y-axis of the
Stems and the Glissando.
I've coded an engraver to set the relevant pointers (from Stem to
Glissando) and use some calculations to get them. This work is done.
(2) Then I intend to move all NoteHeads of intermediate NoteColumns to
sit on the glissando line, making them transparent (or point-stencil
or omit the stencil)
This would have the advantage that LilyPond could do the rest, i.e.
print Stem, Beam, Script etc accordingly.

Obviously the calculation of the intersection points needs to be done
after the Glissando is printed, thus a simple override for
NoteHead.Y-offset will not work, afaict.
>From description in the docs about unpure-pure-containers, this is a
similar situation as for Beams and needed Stem lengths.

Alas, I never came to grips with unpure-pure-containers. Granted, the
explanations/descriptions in the docs improved over the years.
Though, we don't have working coding-examples in the docs, "working"
in the sense of "let me play with the code, testing what happens if I
do this and that":
The example in NR 5.5.6 works with and without unpure-pure-containers.
The example (sort of) in CG 10.13.3 makes no sense to me, at least I
found no situation where "bar" is called at all.
The regtest unpure-pure-container.ly is probably ok as a regtest, it
shows something is done, but why should a user do that at all. As a
user I'd say, don't move the flag if you don't want a moved flag...

That's it for the docs or did I overlook something?

Unpure-pure-containers in LSR: zero

Valentin's example works without unpure-pure-container as well.

Thus, I'm at a loss, close to abandoning the work.

Nevertheless, many thanks,
  Harm

P.S. attached an image what works so far (but don't enable skylines)

glissando-stems-engraver-03.cropped.png
Description: PNG image