[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-user
Subject:    Re: Adding text to chord names or note names
From:       Jean Abou Samra <jean () abou-samra ! fr>
Date:       2022-11-30 14:44:17
Message-ID: f60e03e1-a83b-0e1b-d000-db5c7afc16c2 () abou-samra ! fr
[Download RAW message or body]

[Attachment #2 (multipart/mixed)]

[Attachment #4 (multipart/mixed)]

[Attachment #6 (text/plain)]

Le 30/11/2022 à 05:26, Flaming Hakama by Elaine a écrit :
> I think here is where we dip into the reality that there are many 
> different uses of chord changes.
>
> Chord symbols used for analysis are different than when used as an 
> abbreviation for specific notes/voicings, which is different when used 
> as the basis for improvisation.
>
> I am a practitioner of improvisation, so I am mostly concerned with 
> usage in that realm.
>
> So, for me, "Cm7 omit root" sounds like something plausible a theorist 
> or analyst might think about, but as a player or composer, it is not a 
> thing, it is not something you would write on a page.
>
> As to using chords as an abbreviation for specific notes/voices, if 
> you are trying to get a Cm7 chord by having a bass play the root and 
> an accordion/guitar/piano play Eb major, then there is nothing wrong 
> with writing a chord part that says Eb.  If the bass is also reading 
> the chart, then Eb/C and put an instruction to indicate that only the 
> bass should play the slash notes.  If no one is playing C, then there 
> is no basis for claiming the chord is based on C, and it is confusing 
> to label it anything other than Eb.
>
> We seem to agree that the standard for chord symbols is to simplify 
> root and bass spellings.  I would further suggest that, when using 
> chords to abbreviate voicings, it is best to also simplify spellings 
> of the specific voicings you are attempting to indicate.
>
> So, I am not motivated by this use case.
>
>
> Is the "omit root" the only use case for GSOC?


Well, just like there are people who care about distinguishing 
enharmonically equivalent pitches and people who don't, there are people 
who care about distinguishing chords which have the same pitches, and 
people who don't. The whole purpose of the GSoC work is to make LilyPond 
able to distinguish pitch-equivalent chords when entered via \chordmode. 
If this is not important for you as an improviser, the GSoC work will 
have no interest for you. However, this does not mean it does not have 
an interest for other people with different use cases.


> I will take a look.  As most of my need to tweak parts come from 
> decisions between sharps/flats, rather than neutralize double 
> sharps/flats, I will be curious to see how that is controlled.



The function on the blog post chooses C♯ over D♭, E♭ over
D♯, F♯ over G♭ and B♭ over A♯, leaving G♯ and A♭ as they
are.

Attached is a variant that let you choose which enharmonic
equivalents are picked.



> So, I think we will still want the markup template separated from the 
> way to indicate that you want to use it, and use an identifier to look 
> up a markup template along with the other chord definitions.  Like, 
> could something like this be made to work?
>
> \version "2.22.2"
>
> % Define your desired chord symbol based on the ID "myCustomChordMarkup"
> myChordExceptions = {
> <myCustomChordMarkup>1-\markup { "m7" \teeny "omit root" }
> }
>
> % Use the new chord symbol,
> % extending syntax to provide the ID after a second colon
> myChordSequence = \chordmode {
>     c1:m7^1:myCustomChordMarkup | ees |
> }



You can take the snippet I posted at the beginning and store
myCustomChordMarkup in a plain old variable.


\version "2.23.81"

myCustomChordMarkup = \markup { m7 \teeny "omit root" }

t =
#(define-music-function (text) (markup?)
    #{
      \once \set chordNameFunction =
        #(lambda (sorted-pitches bass inversion context)
           (let* ((root (first sorted-pitches))
                  (root-namer
                   (ly:context-property context 'chordRootNamer))
                  (root-markup (root-namer root #f))
                  (after-slash (if (ly:pitch? inversion)
                                   inversion
                                   bass))
                  (after-slash-markup
                   (if (ly:pitch? after-slash)
                       #{ \markup { / #(root-namer after-slash #f) } #}
                       "")))
             #{ \markup { #root-markup \super #text #after-slash-markup 
} #}))
    #})

myChordNames =
\chords {
   c1
   \t \myCustomChordMarkup d1/g
   \t \myCustomChordMarkup c1/g
}

<<
   \myChordNames
   \transpose c d \myChordNames
 >>



(Note that compared to the original snippet, this also
fixes a bug with inversions.)

Now that you have clarified why you dislike the markup approach,
I think we didn't mean "semantic" in the same sense in the first
place. The "semantics" that this approach loses is that LilyPond no
longer knows about which pitches the chord is made of, apart from
the root and possibly the bass note. Using simple variables, it
is still possible, and wise, to separate the definition of each
chord symbol as finicky markup and its use. (One could also use a
context property similar to chordNameExceptions for that in order
to make the code resemble what you write above.)

Best,
Jean


["enharmonize.ly" (text/x-lilypond)]

\version "2.22.2"

#(define (enharmonize enharmonization-definition)
   (let ((basic-enharmonize (make-semitone->pitch (music-pitches enharmonization-definition))))
     (lambda (pitch)
       (or (basic-enharmonize (ly:pitch-semitones pitch))
           ;; If no enharmonization is specified, remove double/triple
           ;; sharps/flats. Keep sharps and flats as they are.
           (let loop ((pitch pitch))
             (let* ((notename (ly:pitch-notename pitch))
                    (alter (ly:pitch-alteration pitch))
                    (dir (sign alter))
                    (next-notename (+ notename dir))
                    (alter-delta (- (ly:pitch-tones (ly:make-pitch 0 notename))
                                    (ly:pitch-tones (ly:make-pitch 0 next-notename))))
                    (next-alter (+ alter alter-delta)))
               (if (or (zero? next-alter)
                       (eqv? dir (sign next-alter)))
                   (ly:make-pitch (ly:pitch-octave pitch)
                                  next-notename
                                  next-alter)
                   pitch)))))))

#(define (music-transform-property music prop trans)
   (for-some-music
    (lambda (m)
      (let ((val (ly:music-property m prop #f)))
        (if val
            (set! (ly:music-property m prop)
                  (trans val))))
      #f)
    music)
   music)

enharmonizeMusic =
#(define-music-function (def mus) (ly:music? ly:music?)
   (music-transform-property mus 'pitch (enharmonize def)))

enharmonizeChords =
#(define-music-function (def) (ly:music?)
   #{
     \set chordRootNamer =
       #(let ((trans (enharmonize def)))
          (lambda (pitch lowercase)
            (note-name->markup (trans pitch)
                               lowercase)))
   #})


%%%%%%%%%%%%%%%

mus =
\fixed c' {
  ees f g aes bes c' d' ees'
}


{ \mus }
{ \transpose ees gis \mus }
{ \enharmonizeMusic { cis ees fis aes bes } \transpose ees gis \mus }
{ \enharmonizeMusic { } \transpose ees gisis \mus }
{ \enharmonizeMusic { } \transpose ees feses \mus }


chordMus =
\chordmode {
  ees f g aes bes c d ees
}

\chords { \chordMus }
\chords { \transpose ees gis \chordMus }
\chords {
  \enharmonizeChords { cis ees fis aes bes }
  \transpose ees gis \chordMus
}
\chords {
  \enharmonizeChords { }
  \transpose ees gisis \chordMus
}
\chords {
  \enharmonizeChords { }
  \transpose ees feses \chordMus
}

["OpenPGP_signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]