Re: Problem compiling: music-functions-init.ly

[Urs Liska]

Am 14.11.18 um 10:48 schrieb David Kastrup:

Urs Liska <address@hidden> writes:

major 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

As 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)
Issue description:
  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