)
2017-05-28 17:18 GMT+02:00 Charles Winston <chazwi...@gmail.com>:
> 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
> lilypond-user@gnu.org
> 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
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
