On Tue, 01 Nov 2011 04:41:22 -0700, m...@apollinemike.com
<m...@apollinemike.com> wrote:
Where is this advertising? Is it the word prolongation?
Yes. When a beam grob is passed to a function called prolongation people will
at first think the function lengthens the beam.
To make things more consistent, I could call the functions individual-breaking,
strict-breaking, and peters-breaking.
Do these functions break the beam?
I thought they placed the beam, or a part of a broken beam, with different
methods like place-individually align-with-broken-parts
slope-like-broken-parts.
The boolean really means, if 'me' is a segment of a broken beam, then
beam 'me' together with my fellow broken-intos.
Maybe the boolean should be align-broken-segments or something.
Not necessarily - in peters-prolongation, this is set to false for one of the
quants even though we are doing broken beaming (to find the quants of the
individual beam).
That's kind of what confused me. In a case where the upper-level scheme code
is trying to make beam slopes consistent, but not necessarily continuous in
height, you tell the lower-level code consistent_broken_slope=0. I see how it
works, but I would have seen it sooner if the variable name were beelzebub.
My problem is that the boolean consistent_broken_slope doesn't control whether
things are consistent, and affects height in addition to slope. It works at
the detailed level, when quanting a (part of a) beam, choosing whether to align
him with his fellow broken-intos. So I renamed it in my mind as
align_broken_intos
I like do_initial_slope_calculations_ because I think it reads cleaner in the
constructor
That boolean name is fine. My comment was still talking about the interface to
Beam_scoring_problem
http://codereview.appspot.com/5293060/diff/19014/lily/beam-quanting.cc#newcode743
lily/beam-quanting.cc:743: if (do_initial_slope_calculations_)
Even if we made an earlier pass, and avoid the collisions and/or made a
pretty knee, the averaging in peters-prolungation messed up the results
so we would have to do it again.
Exactly.
Should I add this as a comment?
Well, my statement was one of confusion, because I say we /would/ need to look
harder for good positions, but the code says we do not look in this case.
A non-confused comment would help.
http://codereview.appspot.com/5293060/diff/19014/lily/beam-quanting.cc#newcode989
Does this have something to do with X-extents, or Beam::print, or broken
beams?
Yes - because this used to yield two equal quants, the regtests were changing
with my new code even though the values of the quants didn't. The fact that
they fell on correct quants before is pure luck (the correct quant was the
first in the pack). This allows kneed beams to attain the correct values of
the old regtests.
That must have been surprising. Sounds like a pre-commit independent of the
main commit
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
