> ---------- Forwarded message ----------
> From: Jean Abou Samra <j...@abou-samra.fr>
> To: Kieren MacMillan <kieren_macmil...@sympatico.ca>, kbvw <k...@pm.me>
> Cc: "r...@dabble.ch" <r...@dabble.ch>, Koen van Walstijn <
> koen.vanwalst...@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
\dorian c1
\mixolydian c1
or
\mode dorian c1
\mode mixolydian c1
and these would return
c1:1.2.3-.4.5.6.7
c1:1.2.3.4.5.6.7
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,
Elaine Alt
415 . 341 .4954 "*Confusion is
highly underrated*"
ela...@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
