lilypond-devel
[Top][All Lists]
Advanced

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

Re: Improve internal chord structure


From: Carl Sorensen
Subject: Re: Improve internal chord structure
Date: Wed, 29 Mar 2017 23:07:41 +0000
User-agent: Microsoft-MacOutlook/14.7.2.170228


On 3/29/17 2:13 PM, "David Kastrup" <address@hidden> wrote:

>Carl Sorensen <address@hidden> writes:
>
>> On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri"
>> <address@hidden on behalf of
>> address@hidden> wrote:
>>
>>>Thanks for the feedback.
>>>Yes, I should be an enrolled student by May 4.
>>>
>>>Could you give me examples of what you consider an internal chord
>>>structure
>>>(semitone counting?)?
>> The internal chord structure is a Guile (scheme) list containing
>>pitches,
>> a duration, and events.
>
>I beg to differ.  The tangible representation we are working with is a
>list of note events.  When this list of note events is the result of
>chord entry, some additional information is put in to make identifying
>root/inversion possible.

I agree that your statement is more precise.  In my mind, this project is
about deciding what additional information is necessary to give us all the
semantics we would like to have to be able to properly deduce the
appropriate chord name, and how this additional information should be
stored.

>Other forms may be used for the internals of various chord
>naming/identifying routines, but they are an implementation detail.  The
>note events are the information bottleneck that every chord is passing
>through: if the information in there is not sufficient, it has to be
>amended and one has to see how to get the information best into there
>and out again.

If the information in the list of note events is not sufficient, we now
need to guess the semantics.  This GSOC project won't change that; we
aren't proposing to improve our ability to guess the semantics.

We eventually want to get to the point where when we parse something like
e:m7.5-, we don't just get the pitches, but we get the appropriate
semantic information to properly identify this chord in a rational chord
naming system.  So we'd want to capture the root, the quality, the
inversion, and whatever else needs to be captured.  Once we have that, we
can separate the pitch identification from the naming process.  It should
help separate things.

Thanks,

Carl




reply via email to

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