lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Improve internal chord structure


From: David Kastrup
Subject: Re: Improve internal chord structure
Date: Mon, 03 Apr 2017 11:18:45 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]