On Sat, 16 Aug 2014 11:29:29 -0700, Dan Eble <d...@faithful.be> wrote:
On Aug 11, 2014, at 02:43 , Keith OHara <k-ohara5...@oco.net> wrote:
I'll still put NullVoice in \score by default, so it doesn't interact with the
accidental engraver, or anything else that we haven't noticed yet, and let you
\new Staff \with { \accepts NullVoice } when you really want NullVoice included
in the Staff.
Isn’t this backwards?
Not if there are uses of NullVoice as a completely invisible voice. If
NullVoice does not show its own accidentals, alterations on NullVoice notes
should not count for figuring which further notes need visible accidentals.
The bugs with part-combined accidentals seem to arise from the part combiner’s
destroying information (and creating misleading information) by reassigning
notes to other voices. Instead of removing the NullVoice which has the
valuable original information useful to the Accidental engraver, shouldn’t
there be a way to make the Accidental_engraver ignore the voices created by the
part combiner? Here is an example that shows combined issues with accidentals,
lyrics, and dynamics.
\accidentalStyle modern-voice-cautionary
\partcombine \soprano \alto
One person wrote the accidental-setter to accept per-voice accounting; a
different person wrote \partcombine. I don't think either programmer
considered using \partcombine with per-voice accidentals.
A lot of what \partcombine does, printing "solo" and suppressing rests during
solos, and single-stemming unisons, does not seem to be traditional for engraving
four-part harmony. That makes me hope that someone has found a simpler way to combine
two voices per staff without the complications of \partcombine.
Your method of using NullVoices to handle the Accidentals instead of the Voices
seems like a sensible way to adapt LilyPond. The combination of moving
NullVoice to Staff, and changing the other Voices accordingly, could then be a
packaged set of context definitions using the Voice building-blocks in a
different way.
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
