Re: [Lilypond-auto] Issue 1321 in lilypond: Enhancement: add partcombineUp and partcombineDown functions

[lilypond]

Updates:
        Cc: address@hidden

Comment #20 on issue 1321 by address@hidden: Enhancement: add partcombineUp  
and partcombineDown functions
http://code.google.com/p/lilypond/issues/detail?id=1321

Regarding the first part of comment #18: the list of directional grobs for  
the part combiner was introduced with commit
commit b5c032a34d103966f81ecaad177b63cd649719ed
Author: Han-Wen Nienhuys <address@hidden>
Date:   Wed Jan 28 00:01:48 2004 +0000

    * scm/music-functions.scm (determine-split-list): bugfix: only use
    new-active for both voices if both indexes advance. This fixes the
    biggest outstanding problem with new-pc.

    * lily/new-part-combine-iterator.cc (construct_children): set more
    directions.
as
+  char const * syms[] = {
+    "Stem",
+    "DynamicLineSpanner",
+    "Tie",
+    "Dots",
+    "Slur",
+    "TextScript",
+    "Script",
+    0
+  };

At that point of time, the directional grobs in music-functions.scm were  
only
(define direction-polyphonic-grobs
   '(Tie Slur Script TextScript Stem Dots DotColumn))
so it would appear that (apart from the missing DotColumn) the list quite  
intentionally included DynamicLineSpanner explicitly, surpassing what is in  
\voiceOne.

The comment

   /* Mimic all settings of voiceOne/voiceTwo for the two separate  
voices...*/
   /* FIXME: Is there any way to use the definition of \voiceOne/\voiceTwo
             directly??? */

was added only as part of

commit b5603acc6faf05c541353bf2154d73986e2bee0b
Author: Reinhold Kainhofer <address@hidden>
Date:   Sun Sep 26 20:39:33 2010 +0200

    Part-combine: The two separate voices also need proper settings for  
MultiMeasureRest and horizontal-shift


So it would seem that Han-Wen's original intent was quite explicitly
to have the partcombiner put dynamic spanners for the first voice in a
split-voice situation _above_ the line.  What is somewhat absurd is
that DynamicText is _not_ put above the line which does not make a
whole lot of sense.

I'm keeping this off for now: if we want to have the upper voice
dynamics move up by default, we can still do so.  And the user now has
the possibility to do it himself, too, so it's probably not the worst
idea if the default overrides are not too complex so that the user
does not have problems supplying equivalent versions and adding more
stuff.


--
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings