Re: clef change confuses manual key signature

[David Kastrup]

james <address@hidden> writes:

> In the following:
> \version "2.14.2"
> \score {
>    \relative c' {
>       \time 2/4
>       \set Staff.keySignature = #`(((0 . 4) . ,SHARP) ((0 . 3) . ,SHARP))
>       \clef treble
>       c8 a c d
> %%% Commenting out the following line solves the problem %%%
>       \clef bass
>       e fis d c
>    }
>    \layout {}
> }
>
> The clef change causes lilypond to error and not produce output. This
> also errors in 2.15., while 2.12 does not error. Is there some way
> around this?

Ok, consider me annoyed now.  Yes, we have some snippets documenting
this sort of thing, but what is it even supposed to mean?

The actual accidental _code_ knows two kinds of accidental entries: one
_without_ octave entry for the key signature, and one _with_ octave
entry _and_ bar/measure position for signifying a locally changed key
signature by a particular accidental in the music with given note and
octave and time.

The actual code does not try making sense of a _key_ signature entry
_with_ octave (and consequently without bar/measure position).  And what
is a key signature with octave location actually supposed to mean?  Do
we need an accidental for a note in key signature but one octave higher,
or not?

So I fail to make _any_ sense of your example.  If I had to guess, I'd
say the octave specifications are there for overriding the default
octaves chosen by the key signature engraver, but without being fixed to
a certain octave concerning their effect on the music.

However, with _that_ interpretation, a clef change like you propose
above leads to accidentals displayed up in the sky in ledger line
domain.  What's the key engraver to do in this case?  Transpose the
whole octave-enriched key signature down by entire octaves (thus keeping
the arrangement of the scale) until it starts making sense again?  Leave
it in the sky with ledger lines?  Without?

What is your expectation?  For what kind of music and situation is this
useful?

Without an answer to that question, I don't really know the direction
the fix should be taking properly.

-- 
David Kastrup