[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Chords in LilyPond
From: |
Thomas Morley |
Subject: |
Re: Chords in LilyPond |
Date: |
Thu, 25 May 2017 01:56:11 +0200 |
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
- Re: Chords in LilyPond, (continued)
Re: Chords in LilyPond, Simon Albrecht, 2017/05/24
Re: Chords in LilyPond,
Thomas Morley <=
Re: Chords in LilyPond, Thomas Morley, 2017/05/24
Re: Chords in LilyPond, mskala, 2017/05/24