Re: Improve internal chord structure

[Renato Fabbri]

ok, I revised the proposal:
https://docs.google.com/document/d/1aGLfUGgbfV4_izmALUcb0UGQ3k4t-5tOb6rUFNnEIqc/edit?usp=sharing
it is better now with many writing corrections but also with some better
exposition of ideias.
All the changes were minor, but if you know a way for us to upload this
updated version of the proposal,
it might be .worth it.

Best,

On Mon, Apr 3, 2017 at 1:05 PM, Renato Fabbri <address@hidden>
wrote:

> 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
>



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