Re: Potential fix for issue 1504. (issue4237057)

[address@hidden]

On Mar 13, 2011, at 10:30 PM, address@hidden wrote:

http://codereview.appspot.com/4237057/diff/11001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4237057/diff/11001/lily/beam.cc#newcode206
lily/beam.cc:206: orig->set_property ("feather-fraction", scm_cons
(scm_from_double (0.0), scm_from_double (orig->spanner_length ())));
my suggestion was for fraction to be a real fraction, ie. a number from
0.0 to 1.0, relative to the total length of the beam. That also gives
users a way to tune the featheriness they want from their beams (they
could set it to 0.0 - 2.0 to exaggerate the effect for instance), in a
scale-free way.  My idea was also to put the effect of feather-dir into
this pair, ie. feather=LEFT =>  (1.0 . 0.0)  and RIGHT => (0.0 . 1.0)

Does that sound right? I think you would be able to do without
feather-dir in the print callback.

Ah, OK, yes.  Totally doable, although it'd require a convert-ly rule that I'm not sure I know how to write.  But I can work on the code part.

http://codereview.appspot.com/4237057/diff/11001/lily/include/spanner.hh
File lily/include/spanner.hh (right):

http://codereview.appspot.com/4237057/diff/11001/lily/include/spanner.hh#newcode76
lily/include/spanner.hh:76: static int broken_spanner_index (Spanner
const *sp);
this can go now?

Yes, this is vestigial from the last patch (old functions die hard).

http://codereview.appspot.com/4237057/diff/11001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

http://codereview.appspot.com/4237057/diff/11001/scm/define-grobs.scm#newcode329
scm/define-grobs.scm:329: (after-line-breaking .
,ly:beam::calc-feather-widths)
I recommend hooking this up to feather-fraction directly, so you can be
sure it's always calculated at the right time, namely, when needed.

Beyond setting the fractions for all beams,
you'd have to return the fraction pair for the beam part on which the
callback gets called

This is way doable (and will require less code than what I have now), but it'll require more loops.  If you calculate these all at once, you only ever need one loop.  If you calculate it for n broken beams, you need n loops that can break after they hit the correct broken spanner.  This doesn't seem like a lot of overhead, but it does redo some calculations.  If this is OK, I'll implement it.

~Mike