---------- Forwarded message ----------
From: Jean Abou Samra <jean@abou-samra.fr>
To: Kieren MacMillan <kieren_macmillan@sympatico.ca>, kbvw <kbvw@pm.me>
Cc: "rcb@dabble.ch" <rcb@dabble.ch>, Koen van Walstijn <koen.vanwalstijn@me.com>, Lilypond-User Mailing List <lilypond-user@gnu.org>
Bcc:
Date: Mon, 28 Nov 2022 20:27:15 +0100
Subject: Re: Adding text to chord names or note names
Le 28/11/2022 à 15:37, Kieren MacMillan a écrit :
> Hi Koen,
>
>> I still think it could be nice to try to write a longer-term solution.
> There has been a lot of work done on chord naming over the last decade, mainly as part of a Google Summer of Code project a few years ago, but essentially none of it has yet navigated through the patch submission process.
>
> There are lots of people who think it would be nice to write a long-term solution — it just keeps getting stalled (for various reasons). <sigh>
>
>> Do you think there would be any interest in specifying the chord suffixes like that, directly from markup?
> Not sure if I can speak for anyone else, but my interest is (and has always been) in having a robust, unified system with a clean UI that handles most (if not all) of the main use cases.
>
>> in the specific use case of printing a harmonic background, the layer of calculating chords from internal pitches is redundant anyway. There are many ways to think about a chord, and I change the way I think about them all the time: I just want to write it down and I don't need LilyPond to reason about it. :) (Although a root and a bass note are still useful.)
> Make sure you’re up to speed on what’s been done in this area, since some of the groundwork may be complete. And of course there are good reasons that Lilypond has the calculating chords layer — the thing we all want (I think?) is to add functionality without losing what’s already there!
I am not up to speed myself on the various brainstormings that happened
over the years.
What I can at least tell is that the ideas floating around for a unified
note/chords mode are relatively orthogonal to this discussion, as far as
I understand them. The advantages of a unified mode would be
a) less syntax to learn
b) making it more convenient to enter, e.g., piano music, by making it
easy to use \chordmode-like entry for a chord that appears in the middle
of a melody (no chord names involved here).
So it’s more about applying \chordmode syntax to non-chord-names use cases.
The other piece of brainstorming I know about, although I didn’t chase all
the discussions in the devel mailing list, is the GSoC patch. This has the
same goal of making it easier to coerce LilyPond into formatting chord names
the way you want, but does so with a different approach: remember the
details
of how the chord was entered in \chordmode, so that the chord formatting
is closer to the input. Compared to just adding chord symbols with
\markup, that has the advantage that LilyPond understands what the
chords are actually made of, and the disadvantage that it can still be
cumbersome to teach LilyPond how to format the chords the way you
want.
I don't typeset chord names myself, I don't really know how strong the
arguments are for each side. Maybe there's a place for both, maybe not.
At any rate, as opposed to the chord semantics GSoC approach, it would
be rather straightforward implementation-wise to make LilyPond understand
arbitrary chord symbols, as shown in the code from my original reply.
Jean
Going back to the original post here:
> The reasons I would prefer specifying chord name input like that are as follows:
> - For improvised music, harmony is more of a loose "agreement" or "context" for some duration within the piece. It is useful to include it with all the parts.
You can already include chord symbols in all parts.
> - Chord symbols are not really standardized and many different ones are in use.
Lilypond provides ways both to choose among a few of the common approaches, and a way to define your own.
It does not provide a way to use different symbols for the same chord in the same sequence. There are workarounds for that, if it is really desired. But it is not clear that any one engraving should employ more than one way to notate the same chord.
In any case, the suggestion of using text does not address this.
> - Flexibility to come up with new ones is desirable: one example would be to simply specify a mode. Of course this can currently be done by adding to the chord exceptions, but specifying the pitches every time seems redundant if they are not getting printed anyway. ("Who cares, as long as the symbol has meaning to the musicians.")
We can already define new chord types, semantically. It is not clear why you would prefer a non-semantic approach. If your only issue is "specifying the pitches every time" then it seems that you are not aware of the chord input syntax, and are instead using pitches.
Perhaps you should invest in learning the chordmode syntax?
Here is how I would suggest defining the modes using chordmode syntax:
\version "2.22.2"
% An example showing all the modes in a single key
myChordSequence = \chordmode {
\set chordChanges = ##t
% Ionian
c1:1.2.3.4.5.6.7+
% Dorian
c1:1.2.3-.4.5.6.7
% Phrygian
c1:1.2-.3-.4.5.6-.7
% Lydian
c1:1.2.3.4+.5.6.7+
% Mixolydian
c1:1.2.3.4.5.6.7
% Aeolian
c1:1.2.3-.4.5.6-.7
% Locrian
c1:1.2-.3-.4.5-.6-.7
}
% Define your desired chord symbol design
myChordExceptions = {
<c d e f g a b>1-\markup \small " Ion."
<c d ees f g a bes>1-\markup \small " Dor."
<c des ees f g aes bes>1-\markup \small " Phy."
<c d e fis g a b>1-\markup \small " Lyd."
<c d e f g a bes>1-\markup \small " Mix."
<c d ees f g aes bes>1-\markup \small " Aeo."
<c des ees f ges aes bes>1-\markup \small " Loc."
}
% Make these chord symbols available for use
chordExceptions = #(append (sequential-music-to-chord-exceptions myChordExceptions #t) ignatzekExceptions)
% An example melody that works with the demo chord sequence
myMelody = \relative c'' {
b1 a aes fis f ees des
}
% Use the new chord symbols
<<
\new ChordNames {
\set chordNameExceptions = #chordExceptions
\myChordSequence
}
\new Staff \myMelody
>>
% Can be transposed as is
\transpose bes, c <<
\new ChordNames {
\set chordNameExceptions = #chordExceptions
\myChordSequence
}
\new Staff \myMelody
>>
% Demo that this same input syntax works with different roots,
<<
\new ChordNames \chordmode {
\set chordNameExceptions = #chordExceptions
d1:1.2.3-.4.5.6.7 | g:1.2.3.4.5.6.7 | c:1.2.3.4+.5.6.7+
}
\new Staff \relative c'' { b1 | f | fis }
>>
> - Being played in 12ET, there are often distant modulations or chromatic motifs. The whole of it gets transposed for different instruments: for some of those, it leads to many double flats or double sharps. Although I'm a fan of maintaining harmonic relationships and reading at concert pitch in the first place, not everyone is, and sight readers are not pleased with the double accidentals. To solve this, I'm using a function (also found in the snippets) to "naturalize" the pitches to enharmonic ones. However, this then messes up the chord symbols, as the intervals get changed internally.
The only pitches we need to transpose in chord mode are chord roots and slash bass notes. Everything else is identified on input by numeric intervals, and displayed as chord symbols.
It is true that regular transposition rules do not lead to ideal chord roots/bass notes, since we both need to remove double sharps, and sometimes some of the less friendly notes like Cb, E#, and sometimes choosing between F#/Gb or C#/Db based on trying to keep ii7 V7 progressions in the same key.
But this is not something that could be solved by using text markup instead of the usual chord symbols. Both text markup and chord symbols are independent of transposition, only the roots and bass notes need to change.
> - I would like to keep the root notes in a music _expression_, as I would still like to be able to specify duration and automatically transpose the chord symbols. The naturalizing function would then only act on the chord "as a whole", as the chord is just specified as a tonal center with a context added to it in text. Slash chord functionality where both the root note and the bass note get transposed (and the rest of the symbol is text) would be useful, but that sounds like it would be more tricky.
It would probably be possible to write a function that does the root/bass note respellings. However, aside from eliminating double sharps and double flats, choices between sharps and flats are still somewhat arbitrary, so no single function will work in all cases.
I use a low-tech approach: once I transpose a part and it has chord root/bass symbols I don't like, I copy the chords variable, for example "myChords", to a new one named with something like "myChordsForFlats", then I change the few root/bass note spellings that I want spelled differently, then update the appropriate part to use the new chords variable.
Sometimes, the same respelling works for both Bb and Eb transpositions, sometimes, only one needs it, and sometimes they each need their own.
If there is significant duplication that I want to avoid, I might put all the sections with chords that are independent of transposition into their own variables, then the various transposition-specific variables will be composed of references to the common chords variables, plus the chords with respellings appropriate for that transposition. (I am not transposing the original chords, just changing the spellings so that when they are transposed, it yields the desired spellings.)
So, while I agree that the chord root/bass note spellings are a topic, I don't think that any of it motivates using anything other than the existing chordmode functionality.
In particular, using text rather than music representations is usually a bad idea since it removes all semantic information. It is also probably more work to type the markup command than enter the chordmode syntax. If that is not true and you don't like typing c1:1.2.3.4.5.6.7 for mixolydian, you could write syntactic sugar functions so you could say something like
In my opinion, part of the reason there has been no movement on the chord work done as part of GSOC is that it is a solution looking for a problem.
My guess is that, among lilypond contributors, no one has an actual need for this feature, so it is not on anyone's roadmap.
My understanding is that it provides another internal representation of chords. But this is of course only useful if you can do something with that representation, that you cannot do with the existing representations.
In particular, it also suffers from the same chord root/bass note spelling issue under transposition.
Nor does it address how to use different versions of symbols (like triangle vs M vs "maj" for major).
It is possible that the GSOC patch could address a few places where the existing chordmode does not do a great job: bitonal chords (like Amaj7 over G7), and specifying multiple alterations of the same degree, like D7b9#9.
Although there are straightforward workarounds for multiple alterations of the same degree, like specifying d:7.8+.9+.
I am not sure if the GSOC actually took on either of these use cases, but at least those are some cases that could use support, which might lead to the GSOC path being desirable.
So, my prediction is that the GSOC patch will not move forward until someone identifies an actual problem that it addresses.
HTH,
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-