Re: Chords in LilyPond

[Thomas Morley]

'

2017-05-25 16:46 GMT+02:00  <address@hidden>:
> On Thu, 25 May 2017, Thomas Morley wrote:
>> I vaguely remember such threads.
>> Though, could you give some examples (or links) so it is present here as 
>> well?

Hi Mathew,

thanks for collecting the links, examples and your comments about it.
Let me add some own.

> Request for "rootless slash chords" from 2014 but brought up in a thread
> here last month:
>   https://sourceforge.net/p/testlilyissues/issues/3909/
> The discussion on that issue assumes that the user will enter something
> like
>   \chordmode { c c/e c/g }
> to get the desired output of
>   C /E /G
> with LilyPond doing some kind of translation to not show roots when there's
> a slash, but what would make sense would be for the user to enter
>   \chordtext { c /e /g }
> and get
>   C /E /G
> That would be easy by directly printing the input with only formatting
> translations (I am counting the lowercase to uppercase conversion as
> formatting) and much harder with an attempt to go to notes and back in
> between.

Under the link above you'll find two solutions. Ofcourse both scope
with the current way how LilyPond works.
I'll comment on the proposed 'chordtext '-input-mode below.

>
> Request for "alt" notation for chords:
>   http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00644.html
> Here a chord symbol *does not correspond to a fixed set of notes*; it's
> deliberately leaving a choice for the performer, making any translation to
> notes and back difficult.  The thread includes a suggested "solution" of
>   \chords {
>     \once\override ChordName.Text = \markup { G \super { 7 alt } }
>     g:7^5
>   }
> but it sure would be easier to just type
>   \chordtext { G7alt }

We do have a way to print Galt
\new ChordNames \chordmode { g:7.9-.10-.11+.13- }
It is defined in 'ignatzekExceptions'
To get G7alt one could add/replace the relevant setting.

g:7.9-.10-.11+.13- looks ofcourse much more complicated than
\chordtext { G7alt }, though current LilyPond tries to work on the
_same_ chordmode-input to create Staff, ChordNames, FretBoards and
Midi.
So we _need_ to know which pitches are actually to engrave.

The proposed chordtext can't do so, not to speak of reusing the input
transposed or however processed.

I'm not sure yet whether a special chordtext-inputmode (added to the
existing ones) will gain us more confusing than doing us a favor.

> Note the desired symbol does NOT contain a colon or a caret or a 5; why
> are those things needed in the input?

The colon is needed to separate duration-input from pitch-input.
In c8:7 the chord lasts an 8th. In chordtext you would need to find a
possibility to set the duration as well.

The caret may be demonstrated by:

input = \chordmode { b,,1:^3 }
<<
  \new ChordNames \with { chordNameExceptions = \powerChordExceptions }
    \input
  \new FretBoards \input
  \new Staff { \clef "G_8" \input }
>>

All working.

Again \chordtext { B5 } is far easier, but not suitable for Staff and
FretBoards.

> They exist to help LilyPond decide
> on a note set, which is unnecessary for engraving the symbol.  Requiring
> an entire line of override code just for one symbol is a lot to ask, too;
> and yes, it could be achieved with less per-chord work when there are a
> lot of them by defining a chord name override or a macro, but this is
> still a lot harder than just typing
>   \chordtext { G7alt }
> Any ambiguity in what that *engraves* is only at the level of "which parts
> of this symbol does the user want superscripted?".  We cannot expect to
> translate it to notes cleanly without more information about what it
> means, but we don't need to know what it means to engrave it.
>
> This thread:
>   http://lists.gnu.org/archive/html/lilypond-user/2017-02/msg00600.html
> User wants to enter:
>   \chordmode { e13 }
> and get
>   E13
> but instead he gets
>   E9 13
> The reasons for this are arcane,

I strongly disagree with the wording, reread the link, I gave referencies.

> and attempts to "solve" it are predicated
> on deciding which notes are meant to be in an E13 chord when it's not
> otherwise modified - which is not a universally agreed point among
> musicians, and should be completely irrelevant to the question of how to
> engrave the letter "E" and the numerals "1" and "3".

Same as above for Staff, FretBoard and midi.

> At one point in the
> discussion is it pointed out that he could get
>   E13
> by entering
>   \chordmode { e:11.13 }
> but I think it ought to be clear why that isn't ideal.

This was my own suggestion.

>
> This thread:
>   http://lists.gnu.org/archive/html/lilypond-user/2017-01/msg00248.html
> User wants to engrave a chord they describe as "Gm7(b5)/F" and is told to
> type
>   g : m7.5- / f
> Note the desired output does not contain a colon or hyphen.  Using that
> suggestion, as in
>   \new ChordNames { \chordmode { g : m7.5- / f } }
> will actually engrave
>   Gø/F
> (where the ø is superscript).  User doesn't pursue it further, but this
> output does not closely resemble the requested
>   Gm7(b5)/F

I missd this thread.

Gø is done via exceptions and could be solved doing:

\new ChordNames \chordmode {
  \once \set chordNameExceptions = #'()
  g:3-.5-.7/+f
}


> That's just this year's worth.  Four threads in five months.
>
> Counterpoint:  "but MIDI!" is a common argument for why chords ought to
> always have translations to notes.

The following is offtopic for this thread. I'll skip it.

> I use MIDI a lot myself.  But if we
> care so much about MIDI, why can't we have better MIDI support - such as
> the ability to enter arbitrary control changes (ideally: also raw
> hexadecimal bytes, for SYSEXes and such), and to handle repeats correctly?
> In order to get even halfway reasonable MIDI output, I need to write two
> copies of my music, one for engraving and one for MIDI, with as much as
> possible shared between them using variables (but that, in turn, harmed by
> the nonexistence of any real "if" statements).  Really generating correct
> MIDI from the same music used for engraving seems to be a lost cause.
> The usual answer when those things are brought up is that LilyPond is
> about engraving, not about MIDI, and the MIDI features are only meant for
> "proofreading," not to generate high-quality MIDI that could (for
> instance) be fed into a synthesizer for performance.  But if LilyPond is
> not about MIDI, chord names should not be about MIDI either.

Summarizing:
(Close to) all requested stuff is possible even right know. Ofcourse
sometimes using workarounds adding a plethora of code. The input is
sometimes complex and may confuse people, no doubt. But we get the
possibility to have the same input working with Staff, ChorNames,
FretBoards and midi.
This is an advantage which can't be overestimated.

The proposed chordtext-input needs a method to put durations into the
input, but the big advantage is the lack of complexity. Ofcourse the
printing will be not so easy: Brandt-Roemer sometimes propose things
like
E superscripted-b ma ⁷
The disadvantage would be the impossibility to reuse it.
Both, advantage and disadvantage can't be overestimated, imho.


Cheers,
  Harm