Re: Chords in LilyPond

[Winston, Charles R.]

> On May 24, 2017, at 9:40 PM, "address@hidden" <address@hidden> wrote:
> 
>> On Wed, 24 May 2017, Charles Winston wrote:
>> 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:
> 
> Correctly printing chord names - and specifically "Why doesn't the output
> match what I typed?" - is a huge problem for users, and is a recurring
> thread on this list, so I certainly think improvements there would be a
> good thing.
> 
> What I think is most needed is a chord-naming mode that *just prints what
> the user typed*, formatted with the fonts, spacing, and so on that we
> expect for chord names - not translating it to an "internal
> representation" of notes plus extra data as LilyPond "music" at all.  But
> I was shouted down last time I proposed that, I think by people who
> thought I had claimed it would solve all possible obscure problems for
> imaginable hypothetical users.  As I made clear, it would only solve the
> main problem of 99% of relevant users who actually exist, and that wasn't
> enough to satisfy the list.
> 
> Failing a direct "print what I typed" mode, adding a lot of extra data to
> the internal representation while keeping the current framework is the
> hard way to get the input to match the output, but it'd be an improvement
> and we need an improvement.
> 
> -- 
> Matthew Skala
> address@hidden                 People before principles.
> http://ansuz.sooke.bc.ca/
> _______________________________________________
> lilypond-user mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/lilypond-user

Yes, we certainly want the output to match the input. This project strives to 
achieve that. We still need some data structure that can represent that input 
from chord mode and be understood by the chord name engraver--this I call the 
internal representation. The question we should be asking is: how much should 
we base this data structure on the current mode of input? Maybe we should base 
it on the current abilities of chordmode completely, but I believe certain 
aspects of input can be improved as well, and we may want to use this project 
now to create an exhaustive list of characteristics of chords users that might 
not yet be supported by chord mode.

Thanks,
Charles