https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly File ly/music-functions-init.ly (right):
https://codereview.appspot.com/13242056/diff/26001/ly/music-functions-init.ly#newcode1168 ly/music-functions-init.ly:1168: #{ \partcombine \with { \voiceOne } \with { \voiceOne } #part1 In one way, this is cleaner than what I currently have to do to modify one/share/two context properties. (That is refer to the voice contexts in parallel with \partcombine and set their properties.) One thing I like about this is that I don't have to rely on the names of the voices that \partcombine creates. One thing I don't like about it is that I'll have to consult the manual to check which context mods apply to "shared" and which apply to all. I see nothing mnemonic about their position. In short, this is nice, but not clearly better than the status quo, unless there is something I'm missing. Stepping back, for the \partcombineUp use case, I think it would make more sense for the partcombiner to distribute the input notes into just two voices instead of three. Rather than putting notes into Voices "one" and "shared" that need to be configured separately with the same context properties, just direct all top-part notes into "shared" and never into "one." That also has a chance of making some things that would use or iterate over that voice work better. Lyrics come to mind, though NullVoice is a good workaround nowadays. I *think* it would improve the outcome of automatic beaming, but let me find an example before you assume that I know what I'm talking about. https://codereview.appspot.com/13242056/ _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
