I don't know about this one. Certainly, the accidental should be (and is)
printed. It's the naturals that aren't printed. Not even when changing octaves:
\new Staff \relative c' {
\time 6/4
\clef treble
cis dis fis
\clef tenor
c d f
\clef bass
cis dis fis
\clef treble
c' d f
}
Certainly, when changing octaves the accidental (sharp or flat), but I don't
recall for naturals.
On Dec 28, 2010, at 12:41 PM, Phil Holmes wrote:
> Hello,
>
> ----- Original Message ----- From: "Xavier Scheuer" <[email protected]>
> To: "bug-lilypond" <[email protected]>; "lilypond-user"
> <[email protected]>
> Cc: "Philhar" <[email protected]>
> Sent: Tuesday, December 28, 2010 10:53 AM
> Subject: Accidental and clef change issue
>
>
> Hi!
>
> This has been reported on the French user mailing list.
>
> In the following code the c-natural is not printed if there is a clef
> change in the middle of the measure.
>
> \relative c' {
> \clef bass cis2 c
> \clef tenor cis2 \clef bass c % natural is not printed!!
> \clef bass cis2 \clef tenor c
> }
>
> I do not know what say references like Ross, Read about this but I do
> not think this should be the correct behaviour.
> IMHO this is not what a musician (and a user) expect:
> if we have a c-sharp and then a c-natural (at the same octave)
> _in the same measure_, then the natural __MUST__ be printed!
> This is also against what is said in the regtest
> ‘accidental-clef-change.ly’: Accidentals are reset for clef changes
> (note that this regtest works fine but the reported code does not).
>
> Could you investigate this?
> Thanks in advance.
>
> Cheers,
> Xavier
>
> PS: The only "simple" workaround is to use
> #(set-accidental-style 'piano)
>
> --
> Xavier Scheuer <[email protected]>
>
> It's doing what I would expect from reading the regtest - i.e. - when there
> is a clef change, the accidentals are reset to that which you'd expect from
> the key. Therefore, in your example we return to C major, and so there's no
> need to print the accidental. I'd welcome other thoughts as to whether this
> is correct, though.
>
> --
> Phil Holmes
>
>
> _______________________________________________
> bug-lilypond mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/bug-lilypond
_______________________________________________
bug-lilypond mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-lilypond
