Than you Aaron and Jean
On Tue, Dec 29, 2020 at 3:56 AM Jean Abou Samra <[email protected]> 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
>
