Am 25.11.2014 02:45, schrieb Dan Eble:
On Nov 24, 2014, at 04:11 , Urs Liska <u...@openlilylib.org> wrote:
I don't know how to properly review this, but I checked against a current score
I'm working on, and I see it removes one of the most annoying issues I had so
far.
I’m glad to hear that. I still need to check my own scores.
When the partcombiner deals with a section that starts with different rests
(the situation you improve in your patch) it fails to set the Voice number
correctly. I even have the impression it actively sets it wrongly. The attached
image shows that
- at the first moment of the measure the voices are set correctly: The quaver
rest is \voiceOne, the full measure rest is \voiceTwo.
But the notes starting with the second quaver are obviously \oneVoice.
This is outside the scope of this patch.
OK, then I'll write another proper bug report for this.
The following might help work around some frustrating issues. You can put
whatever you like into the same voice the part combiner uses for solos. It’s
not pretty, but it removes uncertainty.
\version "2.19.15"
one = \relative c'' {
c2 c
\voiceOne
r8 c b a g f e d
c1
}
two = \relative c' {
c2 c
R1*2
}
\score {
\new Staff <<
\new Voice = "solo" {
\override Stem.direction = #UP
s1 s2 \override NoteHead.color = #red s2 \revert NoteHead.color
}
\partcombine \one \two
>>
}
—
Dan
Is the following assumption correct?
At the beginning of m.2 the partcombiner treats the crotchet and the
full measure rests as two voices.
At the second crotched, when \one begins to play notes this is
considered "solo" because \two doesn't play at that moment.
When I explicitly instantiate a "solo" voice in the \score block this
will be somehow merged with the voice implicitly created by the
partcombiner.
OK. It seems this may be a way to fix all issues with the output but as
you say it's not pretty. Actually I'd say it's inacceptably ugly. In my
concrete score this would mean I'd have to write such a dummy voice for
the 800 measure piece, for all partcombined instruments.
Best
Urs
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
