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: Flaming Hakama by Elaine
Subject: Re: Adding text to chord names or note names
Date: Tue, 29 Nov 2022 20:26:32 -0800

> Hello,
> Le 29/11/2022 à 23:22, Flaming Hakama by Elaine a écrit :
> > 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.
>
>
> It apparently occurs frequently enough for a GSoC project to have been
> invested in it.
>
> Not an expert here, but Cm7 omit root and E♭ are indeed quite different
> things, a bit like enharmonically equivalent notes.

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?


>
>
> > In any case, the suggestion of using text does not address this.
>
>
> Please clarify. The whole point is that the full name is given for each
> chord without automatic calculation.

So, it is difficult to progress without valid use cases.

As noted, the OP cited the examples of the 6/9 voicing and modes, both of which can be done with existing chordmode, in semantically appropriate ways.

I don't see the "omit root" as a use case that is driving feature development, especially when there is an easy but non-quite semantic way of doing this

\version "2.22.2"

% Define your desired chord symbol design
% Using "b8" as a way to distinguish a rootless chord
myChordExceptions = {
    <c ees g bes ces'>1-\markup { "m7" \teeny "omit root" }
}

% Use the new chord symbol, including the "8-" to indicate a rootless chord
% thus this is not usable for MIDI
myChordSequence = \chordmode {
    c1:m7.8- | ees |
}
myMelody = \relative c'' {
    bes1 | g |
}

% Introduce your additional chord symbol
chordExceptions = #(append (sequential-music-to-chord-exceptions myChordExceptions #t) ignatzekExceptions)

% Use the new chord symbol
<<
    \new ChordNames {
        \set chordNameExceptions = #chordExceptions
        \myChordSequence
    }
    \new Staff \myMelody
>>


>
>
> > It would probably be possible to write a function that does the
> > root/bass note respellings.
>
>
> Yes, cf. my previous post linking to exactly such a function.

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.  

But I agree that, in large part, this is the single biggest issue with transposing chord roots/bass notes, so this likely solves all the actual problems.


>
>
> > 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.
>
>
> The problem addressed by the GSoC code is very clear. It is that \chords
> { c:m7^1 ees } yields "E♭ E♭".
>
> That problem goes away if you use specify chord symbols with text
> markup. Doing that has advantages and disadvantages compared to the GSoC
> code. The whole debate is about the balance of these advantages (some
> find it more convenient) and disadvantages (loss of semantic input,
> although its benefit is not very clear in this case).
>
> Best,
> Jean

Again, I'm not sure what "the problem" is.

As best I can understand, it is a way to override normal chord symbol usage, since normal chord symbol usage has decent coverage.

The main point I want to get across is that the mechanism for rendering a chord symbol should ultimately come down to choosing which markup template to apply to the root and bass note.

This is because the markup, especially for complicated things, but even for good-looking regular symbols, is typically finicky and not something you want to pass in as you are entering chords in chordmode.  And I would want to define them in the same place where the normal chord symbols are defined.

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 |
}



Elaine Alt
415 . 341 .4954                                           "Confusion is highly underrated"
elaine@flaminghakama.com
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

reply via email to

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