lilypond-devel
[Top][All Lists]
Advanced

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

Re: Fixes slope errors from incorrect X extents in Beam::print. (issue 5


From: Keith OHara
Subject: Re: Fixes slope errors from incorrect X extents in Beam::print. (issue 5293060)
Date: Thu, 27 Oct 2011 22:30:42 -0700
User-agent: Opera Mail/11.52 (Win32)

On Thu, 27 Oct 2011 01:34:00 -0700, address@hidden <address@hidden> 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.




reply via email to

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