lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Properties to control placement of accidentals in KeySignatures (iss


From: Keith OHara
Subject: Re: Properties to control placement of accidentals in KeySignatures (issue 6461085)
Date: Thu, 16 Aug 2012 10:41:52 -0700
User-agent: Opera Mail/12.01 (Win32)

On Thu, 16 Aug 2012 01:39:15 -0700, <address@hidden> wrote:

Will the added generality be enough?

Probably:
The remaining restriction is that Key signatures applying to all octaves will 
have sharps on a compact range of positions lines, and similarly flats.  If the 
composer asks for accidentals to be spread out, he either wants them to apply 
to specific octaves, or the reader will suspect they should apply to specific 
octaves, so this case should use the specific-octave form of Staff.keySignature.

And this is a good path to more generality:
The addition of lowest-*-positions properties would better-support adding 
clarifying accidentals in additional octaves.  A Staff.keySignature with the 
usual all-octaves entries, plus extras for specific octaves, supports this case 
for now.


I think the principal aim should be to be able to avoid having to write
overrides in the music itself: changing key/scale and clef should be all
that is needed.

No, the missing feature was to print a key signature (that applies to all 
octaves as usual) in a different way.  The key scale and clef should not 
change. (The former method, specifying key differently to get a different look 
of the key signature, annoyed the programmer who had recently cleaned up the 
automatic accidental code).

The properties controlling how to print a KeySignature belong in the Grob, 
alongside glyph-name-alist and padding-pairs.  We can override once to cover a 
different printing convention over all the key and clef changes in entire score 
:
 \layout {\context {Score \override KeySignature #'highest-flat-positions = 
##(2 3 4 5 -1 0 1)

Maybe the data structure should be a list, so that #'(2 3 4 5 -1 0 1) is ugly 
in the usual way.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]