Am Do., 8. Apr. 2021 um 17:52 Uhr schrieb Jean Abou Samra <j...@abou-samra.fr>: > > > 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
Well, I need correct skylines, at least when it comes to Script, TextScript, Fingerings etc > 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. I'll study the section. For some other details I may have some suggestions. Do you prefer a (private) mail or issue/MR at GitLab? > > 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.". Well, yes, I noticed too, but how could I say whether it's correct or not. unpure-pure-containers are a black box, maybe containing a black hole ;) > 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 > Thanks, Harm