Patchy the autobot says: LGTM. No visible regtest changes. We really should be cleverer about code reviews with their own regression tests. Maybe one can mark them as "improvement" in some manner, and in that case try compiling them in the baseline as well, so that patchy-test has a chance of showing the improvement.
Labels: -Patch-new Patch-review
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've asked that question myself but was too lazy to look into that, thinking that it must be caused by some other code. my guess is that ordering of beaming and completion (decided by mechanisms not yet known to me) lies at the heart. hints welcome, at least on where should I start looking.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
\time 6/4
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 { e4 c8 f g a ~ a b c ~ c b a ~ a g a e f4 }
gives the same beaming. changing time signature to 3/4 breaks the beams both in this version and the new regtest, so it must be a 6/4 beaming pattern problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Looking at the first comparative picture makes clear that the beams are broken here whenever a quarter note intervenes, namely when different circumstances make it impossible to continue. The usual 6/4 beaming exceptions in scm/time-signature-settings.scm state
;; use defaults, but end beams with 32nd or finer each 1/4 beat
((6 . 4) .
((beamExceptions . ((end . (((1 . 16) . (4 4 4 4 4 4))))))))
which, among other things, means that the comment does not match the code. One should likely add a triplet exception like on 4/4, and make either the code match the comment, or the comment match the code, depending on what the desired behavior actually is (my guess would be that the code is correct here).
In other words: I agree with PĂĄl's statement that the beaming is an independent problem (for example, see how the first triplets in the unchanged code are beamed together contraintuitively), and consequently set the patch back to "review".
Labels: -Patch-needs_work Patch-review
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Originally posted by: benko....@gmail.com
(No comment was entered for this change.)
Owner: benko....@gmail.com
Originally posted by: benko....@gmail.com
I hope the attached file shows well the point in the new feature.
Originally posted by: dak@gnu.org
Patchy the autobot says: LGTM. No visible regtest changes. We really should be cleverer about code reviews with their own regression tests. Maybe one can mark them as "improvement" in some manner, and in that case try compiling them in the baseline as well, so that patchy-test has a chance of showing the improvement.
Labels: -Patch-new Patch-review
Originally posted by: dak@gnu.org
Why is everything beamed together in the second bar?
Originally posted by: benko....@gmail.com
I've asked that question myself but was too lazy to look into that, thinking that it must be caused by some other code. my guess is that ordering of beaming and completion (decided by mechanisms not yet known to me) lies at the heart. hints welcome, at least on where should I start looking.
Originally posted by: benko....@gmail.com
writing
\time 6/4
\set tupletSpannerDuration = #(ly:make-moment 1 4)
\times 2/3 { e4 c8 f g a ~ a b c ~ c b a ~ a g a e f4 }
gives the same beaming. changing time signature to 3/4 breaks the beams both in this version and the new regtest, so it must be a 6/4 beaming pattern problem.
Originally posted by: benko....@gmail.com
(No comment was entered for this change.)
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-needs_work
Originally posted by: benko....@gmail.com
I meant comments #6 and 8 to prove that the issue raised by David in comment #4 is absolutely independent of this patch.
Originally posted by: dak@gnu.org
Looking at the first comparative picture makes clear that the beams are broken here whenever a quarter note intervenes, namely when different circumstances make it impossible to continue. The usual 6/4 beaming exceptions in scm/time-signature-settings.scm state
;; use defaults, but end beams with 32nd or finer each 1/4 beat
((6 . 4) .
((beamExceptions . ((end . (((1 . 16) . (4 4 4 4 4 4))))))))
which, among other things, means that the comment does not match the code. One should likely add a triplet exception like on 4/4, and make either the code match the comment, or the comment match the code, depending on what the desired behavior actually is (my guess would be that the code is correct here).
In other words: I agree with PĂĄl's statement that the beaming is an independent problem (for example, see how the first triplets in the unchanged code are beamed together contraintuitively), and consequently set the patch back to "review".
Labels: -Patch-needs_work Patch-review
Originally posted by: benko....@gmail.com
opened new issue
https://code.google.com/p/lilypond/issues/detail?id=2474
about the beaming problem.
Related
Issues: #2474
Originally posted by: ColinPKC...@gmail.com
(No comment was entered for this change.)
Labels: -Patch-review Patch-countdown
Originally posted by: ColinPKC...@gmail.com
Counted down to 20120412, please push.
Labels: -Patch-countdown Patch-push
Originally posted by: benko....@gmail.com
<lilypond@googlecode.com> írta (2012. április 13. 3:29):
could someone please push for me?
Originally posted by: dak@gnu.org
Pushed as [r49e8c80e3282cefff91ad1b5aaff5d91b443ba5e] to staging.
Labels: Fixed_2_15_37
Status: Fixed
Originally posted by: benko....@gmail.com
thank you!
Originally posted by: ma...@gregoriana.sk
(No comment was entered for this change.)
Status: Verified
Originally posted by: dak@gnu.org
Any reason that this does not change Completion_rest_engraver as well?
Originally posted by: benko....@gmail.com
none at all. will work on it.
Originally posted by: benko....@gmail.com
patch adapted for rest engraver in
https://code.google.com/p/lilypond/issues/detail?id=3403
Related
Issues:
#3403.