As I've been working on fixing issue 11, I also ran across a request from Sven Axelsson to change the way beamlets are assigned automatically.
http://thread.gmane.org/gmane.comp.gnu.lilypond.general/66578 Or http://lists.gnu.org/archive/html/lilypond-user/2011-09/msg00208.html As I looked at the various references, it seemed that his request was not only a preference, but a correct request, as it shows the beat subdivisions more clearly. I've now got code that will produce his requested beaming. See new-sven-test.png for the output of the new code. See old-sven-test.png for the output of the existing code. Please let me know whether or not you agree that the new beaming is better than the old beaming. I think I've identified how I can make the switch between the two, but I'm not sure I really want to add a property to do so. I'd welcome opinions in that regard. In running the regtests, I came across one that has some very non-standard beaming, and I think the request in the regtest is wrong. Please see the file old-odd-rhythm.png for the old version of the regtest, and new-odd-rhythm for the new version of the regtest. I believe that old-odd-rhythm is wrong because it implies that the first set of beamed notes and rests total up to an eighth note (or quaver, if I understand british usage correctly), when in fact it is 1/64 short of a full quaver. New-odd-rhythm is odd as well (and it should be, because the rhythm is odd -- with this type of syncopation the quaver should be broken up into a hemidemisemiquaver (did I get this right) tied to a double-dotted semiquaver, which would have a tie at the quaver boundary. At any rate, I think the new beaming for this case is better than the old beaming, because it is less misleading. That being said, I'm not a musical expert, so I'd like your opinions before I go ahead and post this patch for review. Thanks, Carl
<<attachment: new-odd-rhythm.png>>
<<attachment: old-odd-rhythm.png>>
<<attachment: old-sven-test.png>>
<<attachment: new-sven-test.png>>
_______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
