]> git.donarmstrong.com Git - lilypond.git/commitdiff
Issue 2379: resetting autoBeaming after a cadenza
authorDavid Kastrup <dak@gnu.org>
Thu, 31 Oct 2013 11:03:02 +0000 (12:03 +0100)
committerDavid Kastrup <dak@gnu.org>
Sat, 2 Nov 2013 16:07:50 +0000 (17:07 +0100)
Letting measurePosition track the grace state of current_moment
unconditionally keeps it from moving into uncharted territory when
Timing.timing gets switched on or off during grace times.

input/regression/cadenza-grace-autobeam.ly [new file with mode: 0644]
lily/timing-translator.cc

diff --git a/input/regression/cadenza-grace-autobeam.ly b/input/regression/cadenza-grace-autobeam.ly
new file mode 100644 (file)
index 0000000..8340d26
--- /dev/null
@@ -0,0 +1,21 @@
+\version "2.17.30"
+
+\header {
+
+  texidoc = "A grace note after @code{\\cadenzaOff} does not keep
+  autobeaming from resuming properly."
+
+}
+
+\layout { ragged-right = ##t }
+
+\relative c' {
+  e8 e e e e e e e
+  \cadenzaOn <>^\markup \typewriter "\\cadenzaOn"
+  e e e e e e e e
+  \cadenzaOff
+  \bar "|"
+  <>^\markup \typewriter "\\cadenzaOff"
+  \grace f8
+  e e e e e e e e
+}
index fabc74c976f69bae59b31a253650de4a2c49bb0e..67832e3cc5ae60d9fc44154c5f33bfd2061e41f3 100644 (file)
@@ -186,8 +186,6 @@ Timing_translator::start_translation_timestep ()
   else
     {
       measposp = now;
-      context ()->set_property ("measurePosition",
-                                measposp.smobbed_copy ());
     }
 
   int current_barnumber = robust_scm2int (get_property ("currentBarNumber"), 0);
@@ -210,6 +208,22 @@ Timing_translator::start_translation_timestep ()
         }
     }
 
+
+  // Because "timing" can be switched on and off asynchronously with
+  // graces, measurePosition might get into strange settings of
+  // grace_part_.  It does not actually make sense to have it diverge
+  // from the main timing.  Updating the grace part outside of the
+  // actual check for "timing" looks strange and will lead to changes
+  // of grace_part_ even when timing is off.  However, when timing is
+  // switched back on again, this will generally happen in an override
+  // that does _not_ in itself advance current_moment.  So the whole
+  // timing advance logic will only get triggered while "timing" is
+  // still of.  Maybe we should keep measurePosition.grace_part_
+  // constantly at zero anyway?
+
+  measposp.grace_part_ = now.grace_part_;
+
+
   context ()->set_property ("currentBarNumber", scm_from_int (current_barnumber));
   context ()->set_property ("internalBarNumber", scm_from_int (internal_barnumber));
   context ()->set_property ("measurePosition", measposp.smobbed_copy ());