Post by David KastrupPost by Urs Liskamajor and minor are lists with seven number pairs where the cars are
0..6 and the cdrs are 0 or -1/2.
I'm not sure how the definition of custom scales works and how much
freedom the user has to that, but I'd assume that requiring
number-pairs (probably an unspecified number of pairs) with the cars
forming a row of natural numbers should be the right thing.
I am not sure whether sequentiality is an absolute.
I just checked a few things:
1) The order of the cars is irrelevant 2) The cars must be exact
integers 3) If the cdr of a scale step is 0 the pair can be left out.
4) If a car is present more than once then a sharp will dominate
regardless of the order in the list.
5) If a car is < 0 or > 6 a warning "warning: Incomplete
keyAlterationOrder for key signature" is produced but the corresponding
alteration is set => (9 . 1/2) will produce a sharp on the third step 6)
I don't know how one can produce scales with more or less than 7 steps
(but I hope this is possible with LilyPond), but I assume that in case
the behaviour is the same except that the range 0..6 will be different.
7) The cdr of a step may be any number for which there's a key in
KeySignature.glyph-name-alist. Otherwise a warning "warning: No glyph
found for alteration: 1/8" is issued
Post by David KastrupPost by Urs LiskaAs you mention in the other post there should be a specific predicate
(why not `pitch-alist?`).
For now I did
Tracker issue: 5438 (https://sourceforge.net/p/testlilyissues/issues/5438/)
Rietveld issue: 357840043 (https://codereview.appspot.com/357840043)
Give \key command a better predicate for scale type { \key c
major } should not be accepted at the parsing state, turning
"major" into '(major) matching the list? predicate. So instead a
number-pair-list? predicate is being used which is much less likely
to be matched by erroneous input.
This is certainly better than what we had, and I don't think it's likely
to trigger with accidental input like previously.
I think based on my above observations it would be possible to determine
a better predicate than "unlikely to trigger with accidental input".
A key signature mode must
* be a list of number pairs * each car must be an exact integer >= 0 *
each car must occur only once
We can ignore the matching of the cdr I think because the warning is
appropriate and points exactly to the problem.
I'm not sure about the upper range. It's acceptable to ignore the
warning but it feels going in the wrong direction (it's not that the
definition is "incomplete", it's rather an invalid step). If it is
possible to define scales with alternative number of steps it may be
necessary to check that length.
Urs