Thanks for the replies. Today I compiled LilyPond using the repository code. I also went through the Contributor’s Guide, which was very instructive. I hope to send something more specifically about chords after some rest. Best, Renato
On Wed, Mar 29, 2017 at 8:07 PM, Carl Sorensen <c_soren...@byu.edu> wrote: > > > On 3/29/17 2:13 PM, "David Kastrup" <d...@gnu.org> wrote: > > >Carl Sorensen <c_soren...@byu.edu> writes: > > > >> On 3/29/17 8:57 AM, "lilypond-devel on behalf of Renato Fabbri" > >> <lilypond-devel-bounces+c_sorensen=byu....@gnu.org on behalf of > >> renato.fab...@gmail.com> 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 > > -- GNU/Linux User #479299 labmacambira.sourceforge.net _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
