Re: keyAlterationOrder

[Freeman Gilmore]

Than you Aaron and Jean

On Tue, Dec 29, 2020 at 3:56 AM Jean Abou Samra <jean@abou-samra.fr> wrote:

Thank you Aaron and Jean

Hi,

I know that the alist cannot be read with assoc, at least in its simple

form.

I should have said "I know that this list of pairs cannot ..."

Why not?

assoc would read the first key of a given value none of the others keys of

the same value would be read in the chain.

It is at best a stretch to call this property an association list to begin with. An alist is a list of key-value pairs; but this property is a list of step-alteration pairs with no associative semantics. To use this list, you need only filter it to the items you are interested in, and the resulting list will have the items in the desired order. Consider this contrived example:

%%%%
\version "2.20.0"

\new Voice {
  \applyContext
  #(lambda (context)
    (let ((keyAlterationOrder
           (ly:context-property context 'keyAlterationOrder))
          (pitches #{ \fixed c' { cis dis ees fis gis aes bes } #}))
     (set! pitches (map (lambda (pitch)
                         (cons (ly:pitch-steps pitch)
                               (ly:pitch-alteration pitch)))
                        (music-pitches pitches)))
     (format #t "\n  Unordered: ~s" pitches)
     (format #t "\n    Ordered: ~s"
      (filter
       (lambda (elem) (member elem pitches))
       keyAlterationOrder))))

I ran this and got the feeling results.   I see what it does and now understand its purpose of keyAlterationOrde 

}
%%%%
====
Parsing...
Interpreting music...

Unordered: ((0 . 1/2) (1 . 1/2) (2 . -1/2) (3 . 1/2) (4 . 1/2) (5 . -1/2) (6 . -1/2)) Ordered: ((6 . -1/2) (2 . -1/2) (5 . -1/2) (3 . 1/2) (0 . 1/2) (4 . 1/2) (1 . 1/2))

====

Converted from (step . alteration) back to pitch, the final order is: Bb Eb Ab F# C# G# D#. This should make sense given the standard convention of how flats and sharps are arranged   

You are right indeed, it cannot really be called an alist
and assoc is of little use. Thanks for the example.

I think you misunderstood Carl. The order of the alist is the
critical piece of information. This property controls the order
in which alterations are printed in the key. For example:

I originally thought it did; but i can not see the logic by studying the two examples above

If I make  a list, how does  it know where to start and how many accidentals to use in the signature.   I do not want to understand how to write the filter just how to build the list.     I would be using #(define (smufl-key-signature grob)... if keyAlterationOrder would do what i want .

Aaron's reply should answer that.

One question though,   Does the key signature affect the midi output?

Yes, Key_performer generates a key signature meta event (FF 59).

(FF 59)? 

Key Signature efectfs midi.   Next question, If a note in a score has an accidental or natural with it and the same note has an accidental in the key signature how is this affecting pitch?    I think it does not.    If it did, why is the accidental entered with the note, if it is already in the signature.

 "To determine whether to print an accidental, LilyPond examines the pitches and the key signature. The key signature only affects the printed accidentals, not the note’s pitch! "

Please explain?

Absolutely. Note that in MIDI, key signatures are limited to
a number of flats or sharps and a boolean representing major
or minor scale [1]. So the MIDI output is unaffected by
keyAlterationOrder.

I can see that the order would not have an effect on midi.

Thank you, ƒg

Regards,
Jean

[1] http://www.somascape.org/midi/tech/mfile.html#meta