[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Autochange bug and patch

From: Douglas A Linhardt
Subject: Autochange bug and patch
Date: Wed, 17 Mar 2004 09:28:12 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES)


Just FYI, I'm working on a tweak to the autochange feature that would allow the
user to declare that middle C will always be in the lower staff. always in the
upper staff, or (by default) the current behavior.  This is very important in
standard handbell music because middle C is always written in the lower staff.
I already have one solution for this feature, but I'm currently playing with
what I consider a better solution.

However, during the course of playing around with autochange, I ran into the
followin bug.  The autochange iterator always assumes that the autochange music
begins at moment 0.  This causes weird results in code such as the following:

theNotes = \notes \relative c' { a8 b c d e d c b a2 }

        \notes \context PianoStaff
                \context Staff = "up"
                        \autochange \new Voice
                \context Staff = "down"
                        \clef bass
                        s1 * 2

I developed the following patch to fix this problem (below).  When the iterator
is constructed, it stores the current moment as "start_moment_".  When a split
moment (splitm) is read from the split list, it is treated as a delta on top of
start_moment_ when being compared to "now".  When the comparison fails (break
not executed), splitm is "normalized" by incrementing it by start_moment_.

I tried to  normalize splitm before the comparison to "now", but when the
comparison succeeds (break is executed) and the loop continues, splitm would
continue to be incremented by start_moment, yielding somewhat humorous results.
 This problem killed that approach.

Comments or suggestions on this patch are more than welcome.

Caveat:  I haven't had the opportunity to test the following interactions:

        1. autochange music beginning with \partial.

                \autochange \new Voice \partial4 {a4 b c d e}

        2. variable containing \autochange music being referenced in
                multiple places within the piece.

                theNotes = \notes \relative c' \autochange {
                                 a8 b c d e d c b a2 }

                \context Staff = "up"

                ;; Is there 1 autochange iterator that is reused in each
                ;; reference to the variable, or would each reference to the
                ;; variable create its own iterator?

However, the current behavior should have similar problems as patched behavior
in these circumstances (I haven't had an opportunity to check, but my analysis
makes me believe it's so).  I won't have an opportunity to check tonight
(handbell choir rehearsal - HOORAY!), but tommorow night I should be able to
double check these interactions and provide another patch, if necessary.

---     2004-03-16 18:59:29.000000000 -0600
+++ ../../lilypond-2.1.31/lily/  2004-03-16
21:45:17.000000000 -0600
@@ -28,6 +28,7 @@
   SCM split_list_;
   Direction where_dir_;
   void change_to (Music_iterator* , SCM, String);
+  Moment start_moment_;

@@ -93,9 +94,10 @@
   for (; gh_pair_p (split_list_); split_list_ = gh_cdr (split_list_))
       splitm = unsmob_moment (gh_caar (split_list_));
-      if (*splitm > now)
+      if ((*splitm + start_moment_) > now)
        break ;

+      *splitm += start_moment_;
       SCM tag = gh_cdar (split_list_);
       Direction d = to_dir  (tag);

@@ -121,6 +123,7 @@
   Music_wrapper_iterator::construct_children ();
   split_list_ =  get_music ()->get_property ("split-list");
+  start_moment_ = get_outlet ()->now_mom ();

 IMPLEMENT_CTOR_CALLBACK (Auto_change_iterator);

reply via email to

[Prev in Thread] Current Thread [Next in Thread]