On Thu, Mar 30, 2017 at 5:57 PM, <lilypond-devel-requ...@gnu.org> wrote:
> > ---------- Forwarded message ---------- > From: Carl Sorensen <c_soren...@byu.edu> > To: "Winston, Charles R." <charles.wins...@tufts.edu>, " > jefferyshiv...@gmail.com" <jefferyshiv...@gmail.com>, " > lilypond-devel@gnu.org" <lilypond-devel@gnu.org> > Cc: > Bcc: > Date: Thu, 30 Mar 2017 21:19:27 +0000 > Subject: Re: Google SoC > Charles, > > On 3/30/17 8:33 AM, "Winston, Charles R." <charles.wins...@tufts.edu> > wrote: > > > >Anyway, I would love for either of you to pass my draft proposal on to > >the list. It can be found here: > >https://docs.google.com/document/d/1TZLsCovyvqBhahS3Vy7LJMRqyp- > C8ZanHTuCOP > >PTNAg/edit?usp=sharing > > > > > ><https://docs.google.com/document/d/1TZLsCovyvqBhahS3Vy7LJMRqyp- > C8ZanHTuCO > >PPTNAg/edit?usp=sharing> > >Of course, thanks again for all the help. I welcome any and all feedback > >to improve this, and really hope to get to work on this in the summer! > > > Thanks for sharing your proposal. It's a great start. > > The major challenge I see with the proposal right now is that it's > somewhat superficial. It could have been written by someone who just read > what's available on the mailing list, and doesn't reflect much > understanding of what goes on under the hood in LilyPond. I realize that > getting in to LilyPond is a big undertaking, but I think you could make > the proposal shine if you had a bit more clarity on how your work will fit > within the greater aspect of LilyPond. > > For example, your midterm goal is to complete the implementation of the > new representation. But what does that mean? When the implementation is > complete, what will we see? Does it change any input or output? If it > doesn't, how will we know that the implementation is complete? > > Note that I'm not arguing that you need to have input or output by the > midterm deadline. I'm just asking some questions to try to help you > clarify what "implementation is complete" means. The more specific you > can be, the better we will be able to judge your ability to complete the > project. > > Let me know if you have more questions. > > Thanks, > > Carl > Thanks for you interest in improving Lilypond! As someone who uses a lot of chord symbols, I am hopeful that this effort will make Lilypond easier to use. Below are my thoughts after reading your proposal. Before I dive into that, I wanted to offer the observation that discussions about chords in lilypond are often difficult because not everyone is clear that lilypond uses a three step approach: 1) specify chords using input syntax, 2) input syntax is transformed into a set of notes, and 3) the exceptions definitions maps each set of notes to chord name markup. I suppose most people on this dev list are clear about this, but in case anyone isn't here's my little rant and attempt at clarification: http://flaminghakama.com/flaming-lilypond-chords I suspect that the best way to kick off this project is with a survey of the things that: * we currently cannot do * take a lot of effort to do * can only be done with bad semantics Such as: * Omitting the root on chord symbols for repeated slash chords with repeated roots (such as A- /G# /G /F#) * Writing chords with two different alterations of the same extension (such as C7 b9 #9) * Writing different chord symbols for the same chord in different circumstances (such as C- in one case and C- b13 in another). * Having a way to format chord symbols and alterations in different ways (stacked vertically vs horizontally, and in what order) I think that gathering these use cases will be the most valuable part of the process, since what I read in the proposal is a little vague, and greatly overlaps with existing functionality. Which is to say, I disagree that "the first action that will take place is planning, designing, and implementing the modifications to EventChord" because lacking clear use cases, how will you know what a good representation is? Some of the examples above point to additional modeling that is not present in your proposal. (Although perhaps this could be done with your existing proposed model plus some business logic.) "One specific result of this is a simpler and more powerful process of chord naming, being able to name much more complex chords than it is currently able to." I'm not sure that "the process of chord naming" needs to be simpler, or could be made simpler. Most of the properties of the internal representation you suggest (root, quality and extensions, voicing/inversion/bass note) are already represented clearly in the input syntax. The only property you mention that isn't explicit in the chord input syntax is the scale degree. However, if you have set a key signature, then the scale degree could be said to be fully determined. On the other hand, when doing functional analysis of modulations, there are typically cases where a few chords should be analyzed with respect to both the old and the new tonic, and so the concept of scale degree might be independent of the actual chord, and rather be a property of the actual chord plus a reference tone. Regarding displaying chords by scale degree, this is currently possible to some extent, such as: https://lists.gnu.org/archive/html/lilypond-user/2015-06/msg00435.html https://github.com/davidnalesnik/lilypond-roman-numeral-tool Likewise, we can already transpose between keys and chord names with the current approach. "After changing the internal representation, naming and input should also be changed" I'm not sure this follows. Considering the information already present in the current input syntax (with the exception of scale degree,) I'm not sure what would need to be changed. Certainly, in terms of "naming", if there are ways to represent a chord besides the list of notes, then we'd want to be able to leverage that representation when defining chord exceptions. If by "naming" you mean the choice of chord symbols, it is also worth pointing out that there is not a lot of consistency around chord naming, and it is a matter of taste. Since there is no "right" way to do it, it would be difficult to revise it in any way that would be universally helpful. One feature that might close the loop is to allow the exceptions to be defined using the parts of the input syntax, rather than the set of notes. \version "2.18.0" \include "english.ly" % Here is how we currently identify a half-diminished 7th chord % for the purposes of naming myChordExceptions = { <c eflat gflat bflat>1-\markup { m7b5 } } % Would this be clearer? % This specific syntax is obviously not feasible, % since we probably want to define this as a list of pairs % ( [chord definition], [markup callback function] ) myChordExceptions = { m7.5- , -\markup { m7b5 } } There are two general places where I think we could use help. One is that, recognizing that chord naming conventions are not standardized, it would be nice to have a way to switch between different styles. This could mean having a few defaults, similar to \accidentalStyle, which could let you switch between using ignatzek exceptions and others, together with bundles of settings for the different switches for tweaking chord names http://lilypond.org/doc/v2.18/Documentation/notation/displaying-chords#customizing-chord-names The biggest issue we have, as I see it, is a lack of a framework for typesetting chord symbols. For example, most of the tweaks in my custom exceptions are not because I want different symbols than the default, but because I want different (relative) font sizes and positioning of the different elements, either by design (the root should be bigger than the quality, the extensions should be smaller than the quality) or to fix bugs (the triangle/dash/plus/etc. glyphs are not the same sizes). This is where I think the underlying model needs some work. It is not as much a musical model as much as a typesetting model, which at the minimum would include: * root * quality * extensions There are also many things to discuss about here, like: is the 7 in a dominant chord and extension, or a quality? In a dominant 7 #9 chord, are both 7 and #9 qualities, extensions, or treated differently? Personally, I group the 7 from a dominant as a quality along the lines of maj/min/aug/dim, and typeset it larger than other extensions/alterations. Likewise, it would be nice to have some markup patterns for stacking extensions/alterations vertically, and apply those patterns, rather than having to typeset each distinct chord type individually. There would likely be different patterns for stacks with two alterations vs. three, etc. My personal chord styles (also found on the link above), are full of tweaks to get the symbols typeset properly (according to me). Here is what I have to go through to get a pleasing rendition of a minor chord with a major 7th. As you can see, it is largely typesetting and there are no issues with the chord semantics. \version "2.18.0" \include "english.ly" myChordExceptions = { <c eflat g b>1-\markup { \raise #0.6 { \magnify #0.2 { " " } \tiny { \char ##x2013 } \magnify #0.1 { " " }} \raise #0.7 { \magnify #0.5 { " " \triangle ##f } \small 7 } } } chExceptions = #(append (sequential-music-to-chord-exceptions myChordExceptions #t) ignatzekExceptions) myChordSequence = \chordmode { \set chordChanges = ##t \set chordNameExceptions = #chExceptions c1:m7.7+ } myMelody = \relative c'' { r4 c8 ef g b4. } \score { \new StaffGroup << \new ChordNames \myChordSequence \new Staff { \myMelody } >> } I have a lot more ideas about this topic, but I'd like to float these and see what folks think about them. HTH, David Elaine Alt 415 . 341 .4954 "Confusion is highly underrated" ela...@flaminghakama.com self-immolation.info skype: flaming_hakama Producer ~ Composer ~ Instrumentalist -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel