Discussions on LilyPond development

mike@apollinemike.com | 1 Nov 2011 12:41

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

Thanks Keith!
I've incorporated most of your comments into the code and otherwise have a couple questions below.

No change in the regtests & a new patch set up.

Cheers,
MS

On Nov 1, 2011, at 5:19 AM, k-ohara5a5a <at> oco.net wrote:

> This looks more reasonable.
> I read through a few times until I had it figured out.
> I left comments where I really needed either code comments or better
> variable names.
> 
> Do you know the performance cost of turning on peters-prolongation?
> 

There's no extra cost for unbroken beams and a cost of anywhere between 2 & 3 times longer for broken beams, as
it runs two extra quants - one full and one that skips all the inits (this is why the figure is between 2 & 3, as
I'm not sure how long the inits take with respect to the quanting).

> 
> http://codereview.appspot.com/5293060/diff/19014/Documentation/changes.tely
> File Documentation/changes.tely (right):
> 
> http://codereview.appspot.com/5293060/diff/19014/Documentation/changes.tely#newcode68
> Documentation/changes.tely:68: \once \override Beam #'positions =
> #beam::strict-prolongation
> strict-prolongation is the one that returns y-positions at the ends of

(Continue reading)

headers

Keith OHara | 1 Nov 2011 19:59

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

On Tue, 01 Nov 2011 04:41:22 -0700, mike <at> apollinemike.com <mike <at> 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

(Continue reading)

headers

mike@apollinemike.com | 2 Nov 2011 10:14

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

Hey all,

I've decided to pull my patch for issue 1986 off the current countdown.  After incorporating Keith's
suggestions and moving the calculations for a beam's concaveness into Beam_scoring_problem, the patch
has changed significantly enough from yesterday to merit a new countdown.

With these additional changes there are no differences from the previous regtest comparisons save
beam-broken-classic.ly, where strict-prolongation is more accurate (before, errors in the
concaveness calculation led to slight slope discrepancies for strict-prolongation when the slope was flat).

Lastly, there is one regtest change that's been bothering me, and I want to get feedback on it before i push
the patch.  It is in chord-tremolo.ly (see attached).

The shorter stem in the 1/4 bar doesn't bother me (I actually prefer it, but then again, I know nothing about
classical typesetting and don't have access to any of the canonical texts), but it is not consistent with
respect to the 2/4 and 3/4 versions.  This comes from the fact that the 1/4 version doesn't link up with the
stem and thus has a shorter x_span_ than its 2/3 and 3/4 sistren.  The fix is easy (something like x_span_ =
max (x_span_, distance_between_normal_stems);), but I first want to make sure that this is the right
move to make.  Specifically, if Ross, Reed, or Gould have anything to say, please let me know!

Cheers,
MS

>

_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org

(Continue reading)

headers

mike@apollinemike.com | 2 Nov 2011 11:19

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

On Nov 1, 2011, at 7:59 PM, Keith OHara wrote:

> On Tue, 01 Nov 2011 04:41:22 -0700, mike <at> apollinemike.com <mike <at> 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.
> 

Renamed following your suggestions.

> 
>>> 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

(Continue reading)