On Mar 15, 2011, at 9:18 AM, Han-Wen Nienhuys wrote: > On Tue, Mar 15, 2011 at 10:08 AM, m...@apollinemike.com > <m...@apollinemike.com> wrote: >> On Mar 15, 2011, at 9:03 AM, Han-Wen Nienhuys wrote: >> >>> On Mon, Mar 14, 2011 at 9:16 AM, <m...@apollinemike.com> wrote: >>> >>>> I've sketched this out using your suggestion above (calculating it once >>>> and returning the fraction for the called beam) - nevermind my previous >>>> question about redoing calculations. A new patch set is on-line. >>> >>>> I still need to do the math for the longer slopes - I'll have time to do >>>> that later today or tomorrow. >>>> >>>> In the spirit of the one-change-per-push idea, I'd like to push the fix to >>>> 1504 first before I push the change to feather-direction. Does this seem >>>> like a good idea? >>> >>> Do you mean: push an earlier version of this patch first? I think >>> it's not a good idea, because you would rewrite it directly after >>> pushing, cluttering up the history of what is happening. The idea of >>> one-change-per-push is that all the individual changes are >>> independent. >> >> No, I mean that changing the feather-dir property from ly:dir to a pair >> seems like a different problem than fixing issue 1504. It effectively adds >> a new feature to lilypond, and thus seems like it should be the object of >> its own patch/push. However, if you think I > > Ah right. My proposal was for feather-dir to be used to init > feather-fractions (or whatever they're called.) - please do what you > think is best, but if you are pushing 2 commits where the 2nd mostly > rewrites the 1st, you might as well skip the 1st.
I'm going to push the first commit after people sign off on it and then work on the feather-dir bit (w/ the appropriate convert-ly rule). It won't require many rewrites: it'll just require some more math in the calc_feather_fractions function. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
