Properties to control placement of accidentals in KeySignatures

Properties to control placement of accidentals in KeySignatures

[dak, 2012-08-16 08:39:14]

Will the added generality be enough?  Should we not try to come up with some
sort of exception list instead, like we do for mapping chords to fretboards?

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.

[Keith, 2012-08-16 17:32:49]

On Thu, 16 Aug 2012 01:39:15 -0700, <dak@gnu.org> 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.

[dak, 2012-08-16 18:09:51]

http://codereview.appspot.com/6461085/diff/2001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

http://codereview.appspot.com/6461085/diff/2001/scm/define-grob-properties.sc...
scm/define-grob-properties.scm:481: for the clef, such as @code{#(2 3 4 2 1 2
1)}.  These entries apply to clefs
This kind of indexing looks like it would only work for reasonably standard
staffs where this staff-position is constrained to 0..6.

[Keith, 2012-08-17 04:07:18]

On Thu, 16 Aug 2012 11:09:51 -0700, <dak@gnu.org> wrote:

>
http://codereview.appspot.com/6461085/diff/2001/scm/define-grob-properties.sc...
> >  indexed by the staff-position of the first C above centerline
> This kind of indexing looks like it would only work for reasonably
> standard staffs where this staff-position is constrained to 0..6.
>

I sloppily wrote 'centerline' to mean staff-position zero.  I could be more
accurate if I said "the staff-position of the first C with a non-negative staff
position" but hopefully I'll think of something easier to understand.

> http://codereview.appspot.com/6461085/