Re: Chords in LilyPond

[Thomas Morley]

2017-05-25 0:17 GMT+02:00 Charles Winston <address@hidden>:
> Hi LilyPond users,
>
> I’m participating in the Google Summer of Code working on improving 
> LilyPond’s internal representation of chords. The goal here is to create a 
> data structure that will represent a chord’s semantics beyond just a list of 
> notes in the chord. The current representation contains almost no information 
> other than a list of notes, and we want to change this to include other 
> semantic information, i.e. the root, quality, extensions. The current 
> representation causes the chord naming process to infer the correct name from 
> only the notes in the chord, which can create some problems—it would be much 
> better to maintain the information provided by the user in chord mode about 
> the semantics of the chord through to the naming process. Here is a rough 
> list of semantic information I believe should be included in the data 
> structure:
>
>         root note
>         quality (major, minor, augmented, diminished)
>         extension (7, 9, 11, 13, etc.)
>         added notes (6, 9, etc.)
>         suspensions (sus4, sus2, etc.)
>         alterations (flat-5, sharp-9, etc.)
>         omitted notes
>         added bass note
>         inversions


Hi Charles,

I've not yet fully understood what "internal representation of chords" means.

Consider the following example, where I display the arguments which
our current ChordName-printing-function (ignatzek-chord-names) has to
work with:

\layout {
  \context {
        \Score
        chordNameFunction =
          #(lambda (chord-pitches additional-bass inversion-bass context)
            (newline)
            (format #t "chord-pitches:\n~y" chord-pitches)
            (format #t "additional-bass: ~y" additional-bass)
            (format #t "inversion-bass: ~y" inversion-bass)
            (format #t "context: ~a" context)
            (newline)
            (ignatzek-chord-names
              chord-pitches additional-bass inversion-bass context))
  }
}

mus =
\chordmode {
  c:9/e  %% inversion
  c:9/+e %% added bass
  c:9/d  %% inversion
  c:9/+d %% added bass
}

<<
  \new ChordNames \mus
  \new Staff \mus
>>

As an example I c/p the output for the last chord:

chord-pitches:
(#<Pitch c' >
 #<Pitch e' >
 #<Pitch g' >
 #<Pitch bes' >
 #<Pitch d'' >)
additional-bass: #<Pitch d >
inversion-bass: ()
context: #<Context ChordNames () >

So we already identify inversion/additional bass. And in
ignatzek-chord-names the first pitch of "chord-pitches" is taken as
root. Other procedures there try to distribute the remaining pitches
to what is currently called "prefixes", "main-name", "alterations",
"add-steps". "suffixes"



Am I correct assuming you want to have something at the lines of:

((root . <root-pitch>
 (quality . <one-of-major-minor-augmented-diminished>)
 (extension . <extension-pitches>)
 (added-notes . <added-pitches>)
 (suspensions . <suspended-pitches>)
 (alterations . <alterated-pitches>)
 (omitted-notes . <omittes-pitches>)
 (additional-bass . <additional-bass-pitch>)
 (inversion-bass . <inversion-bass>))

internally (i.e. C++) preprocessed from the pitches a user entered
while typing p.e. c:9/d to be delivered to the chordNameFunction?

Cheers,
  Harm