Hi Harm/Carl Harm wrote: > thanks for your reply. > You surely mean the position in x-axis direction for the NoteHeads!? I don't think so (see below)
Carl wrote: > 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. Optical spacing shouldn't be affected. See an elaboration below. I could have done a better job of explaining. Before the Beam decides where it will sit in relation to the notes it needs to calculate where the noteheads (that it's attached to via a stem) are *vertically*. In theory, it's the equivalent of a human looking and seeing where the noteheads are in relation to the middle staff line. If they are all above, the Beam goes below and vice versa. If there are extreme values at both ends you may get a kneed beam that sits in the middle, with noteheads above and below. Once you know where the Beam is, then you can draw the Stems between it and the notes. It seems simple but remember that not all staves have five lines. In practise, the code is very complicated. Most of the complications begin from Beam::consider_auto_knees (beam.cc), in particular where it does this: `head_extents += stem->pure_relative_y_coordinate (common, 0, INT_MAX);` "pure_relative_y_coordinate" tries to figure out where something is on the Y axis in relation to a reference point, which in this case turns out to be the VerticalAxisGroup (IIRC - it's calculated dynamically but I never saw it end up being anything else). Then, in order to calculate where each notehead (technically the stem attach point) is in relation to this group along the Y axis, it needs to know the Y-extent of the axis group, i.e. "how tall is the system". That's when every grob in the system gets pulled into the calculation and there is a long series of function calls of pure_y_something_something... Eventually the pure calls run out. I hope that makes more sense. Kevin
