On Mar 13, 2011, at 10:30 PM, hanw...@gmail.com 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
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
