Alan McConnell <[email protected]> writes: > On Sat, Oct 22, 2011 at 05:35:42PM +0200, David Kastrup wrote: >> >> > Yes! Many thanks! I can see that I'm going to have to get >> > familiar with the "snippets" file. I've ignored it up to >> > now, since I'm working with v 2.14.2. But the code you've >> > suggested works with 2.14.2. > <sigh> There's a problem. I use > ((0 . 6) . ,FLAT) > ((1 . 3) . ,SHARP) > ((0 . 5) . ,FLAT) > for my placement of the accidentals. Using the standard > violin clef, the above settings places the Bb in its > accustomed position, the F# and Ab ditto. The order is > right . . . so far so good. > > But when I put in a C major scale, starting from middle C, the > F(actuall 'fes' in the .ly file) is notated with a sharp! That's > because the sharp in the key signature is an octave higher, as I > discovered from experiment. The A(aes in .ly) and B(bes in .ly) > are notated OK, since they are taken care of by the flats in > the key signature.
Well, _my_ documentation says: To create non-standard key signatures, set this property directly. The format of this command is a list: `\set Staff.keySignature = #`(((octave . step) . alter) ((octave . step) . alter) ...)' where, for each element in the list, `octave' specifies the octave (0 being the octave from middle C to the B above), `step' specifies the note within the octave (0 means C and 6 means B), and `alter' is `,SHARP ,FLAT ,DOUBLE-SHARP' etc. (Note the leading comma.) Alternatively, for each item in the list, using the more concise format `(step . alter)' specifies that the same alteration should hold in all octaves. Now you complain that the same alteration does not hold in all octaves: > Bottom line: the accidentals in a non-traditional key signature > have still got to cover all the octaves! Otherwise great > confusion ensues. > > Maybe this problem is repaired in 2.15? I think the documentation has been around for several years now. > Thanks to Mr Kastrup for his tips on Scheme/guile. I'll read what he > has pointed at with care and, hopefully, understanding<g>. Well, looks like I should point more carefully... -- David Kastrup _______________________________________________ lilypond-user mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-user
