On 4/8/21, 8:22 AM, "lilypond-user on behalf of Kevin Barry" <lilypond-user-bounces+carl.d.sorensen=gmail....@gnu.org on behalf of barr...@gmail.com> wrote: 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).
I think you've done the community a great service by making this process explicitly explained. Thanks for doing this! - 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 The problem with this proposed fix is that it would eliminate optical spacing, which is one of the LilyPond claims to fame for producing beautiful sheet music. A stem-up note followed by a stem-down note deliberately has different spacing than a stem-down note followed by a stem-up note. I doubt that is any help to you, but perhaps someone else will read this and know more. Kevin Thanks, Carl