lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Adding text to chord names or note names


From: Jean Abou Samra
Subject: Re: Adding text to chord names or note names
Date: Wed, 30 Nov 2022 15:44:17 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0

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

Attachment: enharmonize.ly
Description: Text Data

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]