lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: skylines and custom-code


From: Kevin Barry
Subject: Re: skylines and custom-code
Date: Thu, 8 Apr 2021 17:03:07 +0000

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]