Hi, Charles! Welcome to the Pond.
I'm listed as the mentor for the internal chord representation project.
I'd be anxious to provide you any information that you'd like to have.
Here's a data dump of some emails I shared with candidates last year, who
both ultimately decided to work on different projects.
Please review them, and let me know if you have any questions. You can
respond directly to me; I'll reply to both you and lilypond-devel in order
to get the information on the list.
Thanks,
Carl
On 3/21/16 7:23 AM, "Carl Sorensen" <c_soren...@byu.edu> wrote:
>On 3/21/16 1:39 AM, "David Garfinkle" <david.garfin...@mail.mcgill.ca>
>wrote:
>
>>Hi Carl,
>>
>>I'm interested in the Chords project, and am so excited to (finally)
>>apply (at least some) music theory to a programming project, but I have a
>>few questions on my way to making an application. Currently, I am totally
>>confused as to the internal representations
>>of chords. In my work on MusicXML, I recall that Chord Events were lists
>>of Note Events; there was no encoded information of root, inversion, or
>>bass. As I look through the internal reference, the most I can find is
>>music properties (as you said: bass, inversion,
>>root)
>>So my question is, what kind of lily snippet can I test with
>>\displayMusic which will show an internal representation with bass,
>>inversion, and root encoded information?
>
>Try something like \chordmode {\displayMusic c:7/g4}. When we enter
>chords as just a list of pitches (as in note mode) we lose all semantic
>information about the chord.
>
>>Also, what benefit can we get from a richer chord representation? Will it
>>allow for more complex quick-chord creation, like we can do with
>>\chordmode { c1:7 c:m7 c:maj7 c:dim7 c:aug7 } ? Or for built-in music
>>analytic
>>purposes? Or..?
>
>
>We have two fundamentally different definitions of a chord that almost
>overlap, but not quite. One is a set of simultaneous pitches. This set
>of simultaneous pitches is what shows up on the staff, and plays in the
>midi, and shows up in the list of pitches you define above.
>
>The second definition is something that I don't know exactly how to define
>properly, but it's a musical construct that is part of a chord
>progression. It has semantic meaning that goes beyond the list of
>pitches. For example, the three pitches c, e, and gis can be a Caug, Eaug,
>or Gisaug chord. And when we put it in a chord progression, it makes a
>difference, even though when we hear it in midi, it makes no difference.
>
>The basis of this project is to try to make sure that we have a sound
>basis for this second definition -- that we can define the semantics of
>the chord that depend on more than the pitches.
>
>By properly defining the semantics of the chord, we can do the appropriate
>thing when we transpose and when we display chords. Of course, if the
>semantics are not entered in the chord (I.e. the chord is defined in note
>mode), we won't have anything more than the list of pitches.
>
>>
>
>
>
>>
>>I have a feeling I lack some sort of fundamental understanding of
>>Lilypond's internal representation of chords (in that they are not lists
>>of notes) which is making the project fly over my head. Any help is
>>appreciated !
>
>
>At this point, I think we mostly have lists of pitches. I think we want
>to move beyond lists of pitches and include the chord semantics. The
>exact method of internally storing the semantics is certainly not defined
>at this point. But I could imagine something like adding a 'semantics
>entry to an EventChord. The ChordNames context would ignore the 'events
>of the EventChord, and the Staff context would ignore the 'semantics. But
>both would be there.
>
>Frankly, at this point in the project, I don't know exactly how it should
>be implemented. I haven't looked into it that much. I know that we need
>an internal representation of chord semantics, and that once we have that,
>the chord name display/customization problem will be a whole bunch easier.
>
>I hope this has been helpful for you. Please feel free to ask any more
>questions you'd like to.
>
>Thanks,
>
>Carl
>
>
On 3/21/16 10:35 PM, "Carl Sorensen" <c_soren...@byu.edu> wrote:
>On 3/21/16 9:18 PM, "Isaac David" <isacdaa...@isacdaavid.info> wrote:
>
>>Hello again Carl,
>>
>>
>>So this is the final week to submit student applications, I apologise for
>>not
>>getting in touch earlier. The good news is that I have read many docs,
>>including
>>the notation reference manual up to the chord notation chapter, parts of
>>the
>>internals manual related to chords, and even the Lilypond essay. The user
>>documentation is really good; Lilypond feels more powerful and impressive
>>at
>>every snippet and page turn, so to speak. I realized for instance that I
>>was
>>underestimating the input format syntactic complexity when I
>>characterized it
>>as simply LaTeX-like, but I see you are using flex and bison, and this
>>particular project doesn't overlap with the input format anyway, does it?
>
>At its core, this project does not overlap with the input format. If we
>need to add information to the input format (e.g. for stacked polychords,
>in the Brandt and Roemer notation), there may be some potential
>interaction with the input system. But the project could be completed
>without changing the lexer/parser; the internal structure that we need to
>have could be entirely created from Scheme, if that is where we need to
>be. Ultimately we would want to get to the input structure, but that may
>or may not be part of the GSOC project.
>
>>
>>
>>By the way, my development environment is in good shape and working. I
>>haven't
>>built the docs yet though.
>
>Excellent news. You really ought to try building the docs -- set it to go
>overnight so you don't have to wait for it to complete. Your first build
>should be as a single job (no -j option) so that errors will be more
>clear.
>
>>
>>
>>Straight to the point: I would like to make sure that I'm actually on
>>track
>>with your ideas for this project, because after learning about Lilypond
>>chords,
>>the simultaneous music expression and everything in chord mode I fell
>>under the
>>impression that the existing chord modifiers are very complete and
>>powerful
>>enough for the demanding needs of Jazz harmonic constructs, which don't
>>go as
>>far as trying to specify precise inversions (chord/bass idiom aside) nor
>>voicings that span different octaves.
>
>I think that the existing input mode is very good at creating the needed
>Jazz harmonic constructs in terms of pitches, but then LilyPond throws
>everything *but the pitches* away! As an example, the three notes c, e,
>gis form a triad. In fact, they form an augmented triad. It could be
>Caug, Eaug, or GisAug. And there is no way to tell which chord was
>intended by the composer based on the pitches.
>
>The goal of this project is to capture the semantics of the intent in the
>music stream. Right now, all we do is capture the pitches, and in a few
>cases (but not always), we might capture an inversion or a root. This
>makes it very hard to do proper chord naming, because we don't capture the
>intent.
>
>I suspect that the way the project will go will be to somewhat change the
>internal structure of EVentChord. Right now EventChord is a list of
>pitches. The pitches can also have additional properties like inversion
>and bass. But the proper semantics of a chord don't belong to the
>individual pitches; they belong to the *collection* of pitches. So my
>initial working assumption is that we will probably want to add an
>additional data structure to EventChord, which now contains 'elements. We
>may want to have EventChord also contain something like 'semantics (made
>up name, certainly not final). Then a ChordNames engraver would use the
>'semantics entry to produce a chord name, and a Voice engraver or
>performer would use the 'elements information to put the proper notes on
>the staff or in the midi file.
>
>
>
>>Being pedantic with all possible augmented
>>and diminished permutations after each new third interval that gets
>>stacked does
>>reveal very quickly that the
>>named chord modifiers
>><http://lilypond.org/doc/v2.18/Documentation/notation/common-chord-modifi
>>e
>>rs> aren't exhaustive, but they
>>do contain almost everything you could come across in a sheet with chord
>>symbols
>>as far as I can tell. For instance, as soon as triads I found that there
>>was no
>>named modifier for a major-third diminished-fifth (sort of like
>>half-diminished)
>>basic triad. But if those weren't enough the more explicit
>>extended and altered
>><http://lilypond.org/doc/v2.18/Documentation/notation/chord-mode#extended
>>-
>>and-altered-chords>
>>chord notation
>><http://lilypond.org/doc/v2.18/Documentation/notation/chord-mode#extended
>>-
>>and-altered-chords> would suffice for arbitrary complexity. I really
>>liked the
>>features and syntax there, it's very concise.
>>
>>
>>So I imagine the plan is to leave chord mode mostly unchanged and rather
>>build
>>on properties like the existing boolean::bass and boolean::inversion to
>>better reflect chord modifiers after parsing and before feeding
>>Chord_name_engraver. Am I right?
>>
>>
>>I am currently looking at the scm/chord-*.scm files and not feeling
>>terribly
>>lost. I understand the basics of Scheme (nested lists as procedure trees,
>>infix, lambdas, how to save state, the literals, quoted lists, etc.) from
>>reading and hearing about it and other Lisps. However what I'm mostly
>>concerned
>>with right now is understanding the general Lilypond architecture to come
>>up
>>with more concrete plans in my proposal. What are the files I should be
>>looking
>>at? Is there any extra developer documentation I'm missing?
>
>One of the things that is hardest about getting into LilyPond is that
>there is no really good description of the flow of data/transformations
>through the process. I have a mental model, and I've thought about
>creating a document about it, but I'm sure that there are errors in my
>mental model.
>
>The later parts of the Contributor's Guide are the best information that
>we have available. But it's very hard to read, and takes multiple
>iterations to make sense of it.
>
>I'd suggest that you might wish to use \displayMusic with a number of
>chord constructs. For example you can process a LilyPond file containing
>
>\chordmode {\displayMusic {c:maj7.5- c:m7/g}}
>
>
>to see what is created in the music world from these input elements.
>
>Ultimately, we'll need to create the proper internal representation, which
>may require modifications to files or the creation of a new one. At this
>point, I don't know which files these would be. I frankly haven't looked
>that thoroughly at the problem. I've been using some advice given by
>Han-Wen to me more than a decade ago, which was to first focus on defining
>the appropriate internal representation, and then worry about how to
>create that internal representation from an input file.
>
>Once we have the new internal representation, we'll need to change the
>ChordNames engraver to use the proper internal representation. I don't
>think we'll need to change the Voice engraver or performer, because I
>don't think the notes will change.
>
>Let me know if I have left any questions unanswered.
>
>Thanks,
>
>Carl
>
>
>
>
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
