Re: Forcing non-standard accidental behaviour

[Lukas-Fabian Moser]

Is it possible to force Lilypond into using strictly "relative" accidentals?

What I mean by this: A raised 4th in d-major (g-sharp) gets a sharp sign. A raised 4th in f-major (b-natural) gets a natural sign. I want this to get a sharp sign as well; I even want "beses" to be printed with a single flat sign in f major. (In my context, this is not as mad as it certainly seems now.)

>From your name and mail adress I assume that you’re a german-speaking user, so maybe this thread from the archive of the german LilyPond forum helps:

https://archiv.lilypondforum.de/index.php/topic,2119

Thanks much for the pointer! I think, though, that the question discussed in that thread (in German language) concerned something else, which shows that my description as 'relative' accidentals was ambiguous.

The thread in lilypondforum.de concerned the revoking of alterations: after changing b to b-flat, the original poster wanted to restore the b-natural not via a natural sign, but using a sharp sign. Since this applied to music with a fairly limited set of "reasonable" pitch classes, this could be accomplished with hard-coded rules about white keys with accidentals.

What I meant was something else (not 'relative' to music written before, but 'relative' to the key signature): Natural signs can mean flattening or sharping, depending on the key signature. I want to always use flat or sharp signs to express this (and, in consequence, a natural sign in my case should only restore the diatonic tone class to its default absolute pitch class for the given key signature: in f major, a natural sign before a b-flat should still mean b-flat).

What's still true in my case is that we only want to print an accidental in case that also "classically" there would be one, so that an approach via modifying the Accidental stencil might still work. On the other hand, I suspect that the problems in your proposed solution regarding spacing (coming from creating the accidental via a markup) might indicate that it's not yet the "right way", because obviously there are complete routines for printing perfect accidentals. We just want to influence the _choice_ of them.