Re: Attaches bound info to beam for better normalized-endpoint calculations. (issue4605047)
On Jun 23, 2011, at 12:31 AM, Neil Puttock wrote: > On 22 June 2011 22:48, m...@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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attaches bound info to beam for better normalized-endpoint calculations. (issue4605047)
On 22 June 2011 22:48, m...@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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attaches bound info to beam for better normalized-endpoint calculations. (issue4605047)
On Jun 22, 2011, at 11:40 PM, Neil Puttock wrote: > On 16 June 2011 08:18, 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 ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attaches bound info to beam for better normalized-endpoint calculations. (issue4605047)
On 16 June 2011 08:18, 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. ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attaches bound info to beam for better normalized-endpoint calculations. (issue4605047)
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.
http://codereview.appspot.com/4605047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attaches bound info to beam for better normalized-endpoint calculations. (issue4605047)
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.
http://codereview.appspot.com/4605047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attaches bound info to beam for better normalized-endpoint calculations. (issue4605047)
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.
http://codereview.appspot.com/4605047/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: Attaches bound info to beam for better normalized-endpoint calculations. (issue4605047)
thanks, http://code.google.com/p/lilypond/issues/detail?id=1693 http://codereview.appspot.com/4605047/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
