Re: Improve internal chord structure

[Renato Fabbri]

I took all your observations in account (thanks!) and wrote a proposal:
https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-5tOb6rUFNnEIqc/edit?usp=sharing
It is submitted to the GSoC interface.
Is closing time for the proposals, so I should only be able to enhance this
draft.
I should read it again soon and make minor corrections, for example.

Best and Thanks once more!

On Mon, Apr 3, 2017 at 6:18 AM, David Kastrup <address@hidden> wrote:

> Carl Sorensen <address@hidden> writes:
>
> > On 4/2/17 1:13 AM, "lilypond-devel on behalf of Renato Fabbri"
> > <address@hidden on behalf of
> > address@hidden> wrote:
> >
> >>Ok, I looked through the LilyPond code.
> >>
> >>Notes:
> >>*) There seems to be some emphasis on the perspective given in the book
> >>Die Jazzmethode fuer Klavier 1 (Klaus Ignatzek).
> >>Can someone send me a PDF of this book or know how can I find
> >>an online copy at least of the most important parts for this case?
> >
> > I do not have a PDF or a reference.  But I think that the emphasis on
> > Ignatzek need not be exclusive. That is, Ignatzek has a point of view on
> > chords.  So do Brandt and Roemer.  Lilypond should be able to support
> > anybody's view, not just one person's.
> >
> >>
> >>*) Just so I (and other proponents) get it very clear, what do we need
> >>beyond our current capability exposed in the snippet:
> >>http://git.savannah.gnu.org/cgit/lilypond.git/tree/
> >>Documentation/snippets/chord-name-exceptions.ly
> >
> > This capability reflects the current state of LilyPond's chord naming
> > structure, which is to try to guess the name of the chord by analyzing
> > pitches.  So if you want to define a new chord name, you do it by
> > defining the list of pitches in the chord.  It's doable, but the chord
> > itself doesn't carry any semantic information.
>
> Except when it does.  Music properties "inversion", "octavation", "bass"
> carry semantic information beyond the chord pitch.
>
> > The proposal is to put the necessary information describing the
> > semantics of the chord in the chord itself, rather than trying to
> > recreate it from the notes present in the chord.
>
> I am not saying that the current semantic information attached to chords
> by the \chordmode parser is suitable for all purposes and/or
> defined/utilized/documented to the best possible degree.
>
> But ignoring it would make for an awkward start.
>
> > Here's an old proposal that never made it to application:
> > https://lists.gnu.org/archive/html/lilypond-user/2009-01/msg00897.html
> >
> > Here's an interesting discussion on chord names that addresses a
> suspended
> > chord:
> > https://lists.gnu.org/archive/html/lilypond-user/2015-11/msg00864.html
> >
> > Here's another thread that shows problems with chord naming:
> > https://lists.gnu.org/archive/html/lilypond-user/2008-02/msg00391.html
> >
> > Here's an email discussing another possible benefit of the approach:
> > https://lists.gnu.org/archive/html/lilypond-devel/2014-11/msg00155.html
> >
> > And another discussion of some of the challenges:
> > https://lists.gnu.org/archive/html/lilypond-devel/2002-05/msg00069.html
> >
> > Here's one that actually started the thinking for the GSOC project:
> > https://lists.gnu.org/archive/html/lilypond-user/2014-12/msg00617.html
> >
> > Somehow the last thread got broken; here's the follow up:
> > https://lists.gnu.org/archive/html/lilypond-user/2015-01/msg00065.html
> >
> > I hope this is helpful.
>
> Certainly something to look through.
>
> --
> David Kastrup
>



-- 
Renato Fabbri
GNU/Linux User #479299
labmacambira.sourceforge.net