Attaches bound info to beam for better normalized-endpoint calculations.

Attaches bound info to beam for better normalized-endpoint calculations.

Also adds a slight modification to the print function to take into account
the width of the last stem.

[MikeSol, 2011-06-15 08:03:29]

This, in tandem with the modification to spanner_length, leads to better optical
results for feathered beam breaking.

[Graham Percival (old account), 2011-06-15 08:26:22]

thanks,
http://code.google.com/p/lilypond/issues/detail?id=1693

[Neil Puttock, 2011-06-15 21:50:51]

http://codereview.appspot.com/4605047/diff/1/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode564
lily/beam.cc:564: + last_normal_stem (me)->extent (commonx, X_AXIS).length ();
needs parentheses to keep indentation

http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode571
lily/beam.cc:571: + stems.back ()->extent (commonx, X_AXIS).length ();
needs parentheses to keep indentation

http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode591
lily/beam.cc:591: me->set_property (bound_info[d], scm_list_2 (scm_cons
(ly_symbol2scm ("X"), scm_from_double (span[d])),
Hmm, this strikes me as a bit weird; we don't usually set properties at this
late stage.

[MikeSol, 2011-06-16 07:18:30]

On 2011/06/15 21:50:51, Neil Puttock wrote:
> http://codereview.appspot.com/4605047/diff/1/lily/beam.cc
> File lily/beam.cc (right):
> 
> http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode564
> lily/beam.cc:564: + last_normal_stem (me)->extent (commonx, X_AXIS).length ();
> needs parentheses to keep indentation
> 
> http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode571
> lily/beam.cc:571: + stems.back ()->extent (commonx, X_AXIS).length ();
> needs parentheses to keep indentation
> 
> http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode591
> lily/beam.cc:591: me->set_property (bound_info[d], scm_list_2 (scm_cons
> (ly_symbol2scm ("X"), scm_from_double (span[d])),
> Hmm, this strikes me as a bit weird; we don't usually set properties at this
> late stage.

left-bound-info and right-bound-info are calculated at the beginning of
Line_spanner::print, so this setting of Beam properties, albeit late in the
game, would be in keeping with the stage at which these properties are
calculated in the Line_spanner.  Granted, I could be using one bad practice to
justify another, but it seems like in the Line_spanner case, this is an
appropriate place to calculate this information.

[MikeSol, 2011-06-22 13:05:57]

On 2011/06/16 07:18:30, MikeSol wrote:
> On 2011/06/15 21:50:51, Neil Puttock wrote:
> > http://codereview.appspot.com/4605047/diff/1/lily/beam.cc
> > File lily/beam.cc (right):
> > 
> > http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode564
> > lily/beam.cc:564: + last_normal_stem (me)->extent (commonx, X_AXIS).length
();
> > needs parentheses to keep indentation
> > 
> > http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode571
> > lily/beam.cc:571: + stems.back ()->extent (commonx, X_AXIS).length ();
> > needs parentheses to keep indentation
> > 
> > http://codereview.appspot.com/4605047/diff/1/lily/beam.cc#newcode591
> > lily/beam.cc:591: me->set_property (bound_info[d], scm_list_2 (scm_cons
> > (ly_symbol2scm ("X"), scm_from_double (span[d])),
> > Hmm, this strikes me as a bit weird; we don't usually set properties at this
> > late stage.
> 
> left-bound-info and right-bound-info are calculated at the beginning of
> Line_spanner::print, so this setting of Beam properties, albeit late in the
> game, would be in keeping with the stage at which these properties are
> calculated in the Line_spanner.  Granted, I could be using one bad practice to
> justify another, but it seems like in the Line_spanner case, this is an
> appropriate place to calculate this information.

Patch updated so that it only deals with bound info.
Please reply with any and all questions/concerns.

[Neil Puttock, 2011-06-22 21:40:55]

On 16 June 2011 08:18,  <mtsolo@gmail.com> wrote:

> left-bound-info and right-bound-info are calculated at the beginning of
> Line_spanner::print, so this setting of Beam properties, albeit late in
> the game, would be in keeping with the stage at which these properties
> are calculated in the Line_spanner.

They're calculated via callbacks, not directly in the C++ code.

[mike_apollinemike.com, 2011-06-22 21:48:33]

On Jun 22, 2011, at 11:40 PM, Neil Puttock wrote:

> On 16 June 2011 08:18,  <mtsolo@gmail.com> wrote:
> 
>> left-bound-info and right-bound-info are calculated at the beginning of
>> Line_spanner::print, so this setting of Beam properties, albeit late in
>> the game, would be in keeping with the stage at which these properties
>> are calculated in the Line_spanner.
> 
> They're calculated via callbacks, not directly in the C++ code.

In this present case, I could see the bound info being calculated via a callback
that fetches the 'quantized position property for the Y values, but the X values
would still need to be calculated by consulting the normal stems à la lines
559-570.  Were I to place the calculation in a callback, it would require a code
dup of these lines.  To avoid this, I could create a property called x-positions
and change the name of positions to y-positions and quantized positions to
quantized-y-positions.  Then, I'd put lines 559-570 in a separate callback for
the X positions.  Lemme know if this sounds good.

Cheers,
MS

[Neil Puttock, 2011-06-22 22:31:42]

On 22 June 2011 22:48, mike@apollinemike.com <mike@apollinemike.com> wrote:

> In this present case, I could see the bound info being calculated via a
callback that fetches the 'quantized position property for the Y values, but the
X values would still need to be calculated by consulting the normal stems à la
lines 559-570.  Were I to place the calculation in a callback, it would require
a code dup of these lines.  To avoid this, I could create a property called
x-positions and change the name of positions to y-positions and quantized
positions to quantized-y-positions.  Then, I'd put lines 559-570 in a separate
callback for the X positions.  Lemme know if this sounds good.

I think I'd rather you keep the slightly unidiomatic code than rename
properties (particularly since renaming positions will affect other
grobs).

Cheers,
Neil

[mike_apollinemike.com, 2011-06-22 22:43:52]

On Jun 23, 2011, at 12:31 AM, Neil Puttock wrote:

> On 22 June 2011 22:48, mike@apollinemike.com <mike@apollinemike.com> wrote:
> 
>> In this present case, I could see the bound info being calculated via a
callback that fetches the 'quantized position property for the Y values, but the
X values would still need to be calculated by consulting the normal stems à la
lines 559-570.  Were I to place the calculation in a callback, it would require
a code dup of these lines.  To avoid this, I could create a property called
x-positions and change the name of positions to y-positions and quantized
positions to quantized-y-positions.  Then, I'd put lines 559-570 in a separate
callback for the X positions.  Lemme know if this sounds good.
> 
> I think I'd rather you keep the slightly unidiomatic code than rename
> properties (particularly since renaming positions will affect other
> grobs).

Fair 'nuf.  All of this stems from the feature of Beams whereby coordinates are
calculated in terms of X/Y instead of left/right - I think it's the only spanner
that will pose this problem.

Cheers,
MS