Am Mo., 5. Apr. 2021 um 13:48 Uhr schrieb Jean Abou Samra <j...@abou-samra.fr>:
>
>
> Le 05/04/2021 à 12:00, Thomas Morley a écrit :
> > 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)
>
> Harm,
>
> Could you send the code you have so far? I'd like to give
> fixing the skylines a try.
Hi Jean,
I'll send it privately, I always hesitate to make wip-code public on
the user list
The problems start likely early in `line-spanner-gradient', there I
take the stencil to finally calculate the gradient, because the values
in left/right-bound-info are not accurate for broken glissandi.
`adjust-stems-beams' is the general definition to derive
`stem::adjust-for-glissando' (as a stencil-override) and
`beam::adjust-for-glissando' (as a positions-override) from it.
But maybe this is not the best way...
Best,
Harm
>
> I totally agree that unpure-pure containers are a headache
> to understand. The docs could certainly use an update
> (I'll have some news to share about that shortly). The
> problem is, it's pretty difficult to find a compelling
> example for pure functions. With, say, engravers, you
> can write: here's a nice engraver that highlights part
> of the music, or draws lines between any two notes, etc.
> With pure functions, all you have is: this pure-unpure
> container is the only way to avoid a cyclic dependency;
> or: with this pure function, the spacing is slightly
> snugger, observe how the second system is 1 cm higher.
> It's not as exciting...
>
> The only example I can think of is
>
> \version "2.23.2"
>
> % #(ly:set-option 'debug-skylines)
>
> \new Voice \with {
> \override TextScript.Y-extent = #ly:grob::stencil-height
> }
> \repeat unfold 300 { c'^\markup \column { a b c d e f } }
>
>
> The default for TextScript.Y-extent is
> grob::always-Y-extent-from-stencil, which is defined as
> (output-lib.scm):
>
> ;; Using this as a callback for a grob's Y-extent promises
> ;; that the grob's stencil does not depend on line-spacing.
> ;; We use this promise to figure the space required by Clefs
> ;; and such at the note-spacing stage.
>
> (define-public grob::always-Y-extent-from-stencil
> (ly:make-unpure-pure-container ly:grob::stencil-height))
>
> With just ly:grob::stencil-height, it is assumed that
> the height of the grob might depend on line breaking.
> Thus, it is not taken into account during page breaking.
> This causes too many systems to be placed on the page.
>
> Probably not overly helpful, but it was the best I could do...
>
> Regards,
> Jean
>
