On Thu, 27 Oct 2011 01:34:00 -0700, m...@apollinemike.com
<m...@apollinemike.com> wrote:
What about the x_span_ of the Beam_scoring_problem ?
It represents two things at two different stages of Beam_scoring_problem.
Too bad you didn't use two different variables.
Starting at update_x_span_after_extremal_hangover_compensation (), the x_span_
becomes the real span of the beam, tacking on left and right overhang that may
come from stemlets or broken beams. This is necessary for the quanting (we
always want edges quanted) but not possible for the slope calculations, which
are predicated on the idea that unquanted_y_ represents the beginning and end
of the beam (otherwise, we'd have to compensate for extremal hangover in each
function).
You are telling me _what_ happens, which I could see from the code. Some things
looked strange, possibly accidental, so I wanted to know _why_.
I see that the slope-determining steps are influenced by note-heads, so the
interval with normal stems is _slightly_ more convenient to use there. I notice
that least_squares_positions() has a comment wishing it could see the note-heads
on the other portion(s) of a broken beam, for exactly your purposes.
The interface through \override Beam 'positions used to control heights at the
positions of the first- and last- normal stems, but that wasn't documented --
or very convenient in case of overhangs.
You make a good point that quanting should work with the ends of the full beam
as printed including overhangs, but I assume that change is a separate commit.
The difference between
consistent_broken_slope_ and consistent_broken_slope is dangerous all by
itself.
I'm not sure what you mean - how is this dangerous?
Similar names (formerly also similar to the property 'consistent-broken-slope)
with different values. Only dangerous if someone changing the code later is
un-careful about distinguishing them. The new patch is better about this.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
