Menu
▾
▴
#3633 Patch: Freeze measurePosition while Timing.timing is off
Originally created by: *anonymous
Originally created by: dak@gnu.org
Originally owned by: dak@gnu.org
Freeze measurePosition while Timing.timing is off
Also don't reset it in \cadenzaOff, and leave autoBeaming alone in
\cadenzaOn/\cadenzaOff. This should cause quite fewer interferences
of cadenze with timing, accidentals, barlines and other stuff.
Originally posted by: dak@gnu.org
(No comment was entered for this change.)
Owner: dak@gnu.org
Originally posted by: dak@gnu.org
Patchy the autobot says: passes tests.
Labels: -Patch-new Patch-review
Originally posted by: pkx1...@gmail.com
Patch on countdown for October 31st - 06:00 GMT
Labels: -Patch-review Patch-countdown
Originally posted by: pkx1...@gmail.com
Patch counted down - please push
Labels: -Patch-countdown Patch-push
Originally posted by: dak@gnu.org
Pushed to staging as
commit [re54a1a9761969ec0609ded9588a46a7ff40ca74e]
Author: David Kastrup <dak@gnu.org>
Date: Sat Oct 26 08:22:18 2013 +0200
Issue 3633: Freeze measurePosition while Timing.timing is off
Also don't reset it in \cadenzaOff, and leave autoBeaming alone in
\cadenzaOn/\cadenzaOff. This should cause quite fewer interferences
of cadenze with timing, accidentals, barlines and other stuff.
I'm tempted to include this into 2.18 as it does not really seem to affect any of the examples used in the documentation but leads to saner behavior when a cadanza does not start (and consequently stop) at a bar boundary.
However, there is no extensive evidence yet how this approach combines with autobeaming and manual beaming (note that even manual beams are affected by measure position, for example when orienting beamlets).
I consider it likely that this will fall in the "not more inconsistent/unusable than before" category, but there's no evidence yet.
Labels: -Type-Enhancement -Patch-push Type-Defect Fixed_2_17_30
Status: Fixed
Originally posted by: Elu...@gmail.com
(No comment was entered for this change.)
Status: Verified