Re: Chords in LilyPond

[Thomas Morley]

)

2017-05-28 17:18 GMT+02:00 Charles Winston <address@hidden>:
> Hi all,
>
> There have been some great discussions about new chord functionality you’d 
> like to see in LilyPond. The first step is defining the internal 
> representation. From there, I think all these issues can be much more easily 
> solved. We have the EventChord structure, which contains an ‘articulations 
> and ‘elements entry. The ‘elements entry contains some information about the 
> root and inversion, but otherwise it is a list of NoteEvents to be iterated 
> over. My plan is to add a ‘semantics entry whose elements will be semantic 
> aspects of the chord:
>
>         -root
>         -quality of the third (minor, major, none)
>         -quality of the fifth (diminished, perfect, augmented, none)
>         -extensions (7, 9, 11, etc.)
>                         my plan for this is to have a list of extensions, 
> each extension associated with a bool indicating its presence in the chord,   
>                 and associated with an alteration.
>         -added notes (6, 9, etc.)
>                         implemented similarly to extensions above
>         -suspensions (sus4, sus2, etc.)
>         -added bass note
>         -inversions
>
> Let me know what more should be added to this list.
>
> So after this is implemented, we have an internal representation of a chord, 
> EventChord, which contains both note information and semantic information, 
> and each of these can be utilized independently in different contexts.
>
> Let me know what you guys think.
>
> Thanks,
> Charles
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user

This sounds like you want to write a chord-analyser or probably a
better wording would be chord-interpreter.
Disregarding the fact different people may interpret different,
LilyPond does this already _inside_ of the
chord-name-printing-function (ignatzek-chord-names).
The pitch-list which ignatzek-chord-names works on is splitted into
ROOT PREFIXES MAIN-NAME ALTERATIONS SUFFIXES ADDITIONS
(comment from chord-ignatzek-names.scm)
Attached an image where I tweaked ignatzek-chord-names to output
things colored, bold, boxed. The input-code:

chrds-test = \chordmode {
  \cadenzaOn
  \accidentalStyle forget
  <c' e' gis' bes' d'' f''>
  <c' e' g' bes' d'' f''>
  <c' ees' gis' bes' d'' fis''>
  <c' ees' gis' a' bes' d'' fis''>
  \bar "" \break
  <c' d' e' gis' bes' d'' f''>
  <c' d' e' g' bes' d'' f''>
  <c' d' ees' gis' bes' d'' fis''>
  <c' d' ees' gis' a' bes' d'' fis''>
  \bar "" \break
  \once \override NoteHead.color = #red
  <c' e' gis' bes' d'' f'' bes>_"ChordName is rubbish"
  c:5+.7.9.11/+bes
  <c' e' g' bes' des'' ees'' fis'' aes''>
}

<<
  \new ChordNames \chrds-test
  \new Staff \chrds-test
>>

You will notice some strange things. And one naming is completely rubbish.


Doing this interpretation _inside_ of the printing function is one of
the big problems I have to state with current LilyPond.

Though, why adding a ‘semantics entry to the EventChord?
I'd suggest to write such an interpreter as a procedure which works on
the pitchlist ignatzek-chord-names currently has to work with
(including bass/inversion-info). Then write a printing-function which
works on the result of the interpreter.
Both public in guile, so that users can write different interpreters
and printing-functions as they like.

The other problem can be watched in my example above. (The rubbish chord-name)
If chords are entered as < ... > there's no nice way to specify bass/inversion.
Currently I've no good idea to solve this, though.

Cheers,
  Harm

atest-60.png
Description: PNG image