Re: Chords in LilyPond

[mskala]

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?

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.

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 }
Note the desired symbol does NOT contain a colon or a caret or a 5; why
are those things needed in the input?  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, 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".  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 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

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

-- 
Matthew Skala
address@hidden                 People before principles.
http://ansuz.sooke.bc.ca/