Re: skylines and custom-code

[Jean Abou Samra]

Le 08/04/2021 à 16:21, Kevin Barry a écrit :
> Hi Harm,
>
> > Ok, another 5 days passed working allday on the problem, progress: zero.
> > I give up.
> >
> > Some insights:
> > (1)
> > It would have been helpful to understand how Stems fit into a Beam,
> > then I could use this knowledge to probably do similar with glissando
> > and Stems.
> > I was not able to figure it out.
> > (2)
> > Obviously the Stems needs to be positioned after Beam (or Glissando) is done.
> > An unpure-pure-container looked promising.
> > Though, I was not able to code even the simplest via native scheme.
> > This leads to the conclusion that unpure-pure-containers are not
> > accessible/customizable for users like me.
> > At least unless much more working examples are done in the docs.
> I haven't had time to try and understand your issue, but having worked
> on problems with Stems and Beams in the past I think it's an area of the
> code that could be improved, because there is an effective circular
> dependency:
> - Stems check Beams in order to determine their direction/position etc
> - Beams check where the first and last noteheads are - compared to the
>    whole system - to try and figure out on which side they should be on
>    or if the beam should be kneed, etc
> - Checking where noteheads are in relation to the whole system triggers
>    lots of other grob calculations. If any of these calculations check
>    the Beam or the Stem you get a circular dependency (I fixed at least
>    one regression in this area where DynamicText was triggering the
>    circular dependency).
> - If you try to dive into all the consequences of the code that
>    calculates a Stem's direction it is almost impossible to understand.
>    It's a long chain of pure/unpure calls - maybe 50 stack frames of just
>    that stuff (IIRC); completely impenetrable (for me at any rate)
> - In my opinion, the fix is to find a way to figure out notehead
>    positions without calculating everything else, then Beams, then Stems
>
> I doubt that is any help to you, but perhaps someone else will read this
> and know more.
>
> Kevin


Hi Harm and Kevin,

My apologies, I got swamped in other things and didn't look
at the problem since I unsuccessfully tried when you sent
the code.

One thought: it's not very pretty, and maybe I'm just being
dumb, but why not remove the skylines completely?

  \temporary \override NoteHead.vertical-skylines = ##f

It looks like the glissandi are enough to provide their
own skylines.

On the general issue of purity: indeed, it is euphemism
to say that it is thorny. Today I've been filling
https://extending-lilypond.readthedocs.io/en/latest/backend.html#unpure-pure-containers
and I left it with a bunch of TODOs because I just
have no clue.

To comment on Kevin's insights -- thank you! --, the enormous
dependency graph is the big problem with pure functions in my
opinion. There are so many possible paths that it is extremely
easy to trigger cyclic dependencies.

The other big problem is that the caller, not the callee,
determines whether the pure or the unpure version of a
callback is used. I stumbled upon this:

{
  \override NoteHead.Y-offset =
    #(ly:make-unpure-pure-container
       (lambda (grob)
         (ly:message "UNPURE")
         0)
       (lambda (grob start end)
         (ly:message "PURE")
         0))
  c'1
}

Guess what? It prints "UNPURE". Before "Finding the ideal
number of pages.".

That does not sound correct. The default for
NoteHead.Y-offset is

(define-public staff-symbol-referencer::callback
  (ly:make-unpure-pure-container ly:staff-symbol-referencer::callback))

Something is triggering the unpure callback while
it should use the pure one.  Go figure.  At any
rate, this means it is impossible to make separate
pure and unpure callbacks for NoteHead.Y-offset.

Sigh.

Best,
Jean