Re: Google SoC

[Flaming Hakama by Elaine]

On Thu, Mar 30, 2017 at 5:57 PM, <address@hidden> wrote:

>
> ---------- Forwarded message ----------
> From: Carl Sorensen <address@hidden>
> To: "Winston, Charles R." <address@hidden>, "
> address@hidden" <address@hidden>, "
> address@hidden" <address@hidden>
> 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." <address@hidden>
> 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"
address@hidden
self-immolation.info
skype: flaming_hakama
Producer ~ Composer ~ Instrumentalist
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-