On 2011-01-31 11:04, Jan Warchoł wrote:
> [...] If the last note in the
> following example doesn't get a natural, it's *impossible* to tell
> that it's not another ces:
>
> ces'1~ | ces'
> ces'1( | c')
>
> It may be argued that the slur looks different than the tie, but it's
> not enough.
> I'm sure that engraving books will agree with me - may someone check this?
Now that I have a brand new copy of Gardner Read's "Music Notation" in
my bookshelf since just yesterday, I do. I didn't yet read the whole
book, though...
In the chapter for accidentals (p. 131), it says:
"It is not necessary to repeat the accidental before a tied note. The
tie itself serves to prolong the effect of the accidental. The one
exception to this general rule occurs when the note or notes affected by
an accidental and tied over the barline come at the end of a system or
at the bottom of the page."
Which is what we all know.
Regarding slurs, I found exactly nothing. But I'm absolutely sure, if
Read had written anything about it, it would be: "If in doubt whether
the reader will know what to do: make it clear." Or, rather: "Write the
natural, dummy." He constantly advocates the use of notation that eases
the understanding of the music, and disapproves any elements that are
hardly possible to distinguish or perform.
And this may be an example just too obvious that he felt the need to
comment it.
Not that I know a single instance where this occurs, though. In a piano
piece that requires a moderately trained player, perhaps I'd leave it
out; but only in the case of chords which are very clear to interpret.
Yet, in any other case, I consider it good style to write the natural
even when there's no slur. In particular for a single voice, say a
two-note melisma in choral music.
By the way: if you have { r2.. cis8( | c2!) r2 } all over the place,
and then there suddenly comes a { r2 cis2~ | cis2 r2 }, you'd expect an
additional sharp there too, don't you?
Just my two pence...
Cheers,
Alexander
_______________________________________________
bug-lilypond mailing list
bug-lilypond@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-lilypond
