Re: Charles Winston's chord-semantics GSOC work

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Charles Winston's chord-semantics GSOC work

Flaming Hakama by Elaine
> ---------- Forwarded message ----------
> From: Carl Sorensen <[hidden email]>
> To: "[hidden email]" <[hidden email]>, "
> [hidden email]" <[hidden email]>, Carl Sorensen <
> [hidden email]>, "[hidden email]" <[hidden email]>, "
> [hidden email]" <[hidden email]>, "
> [hidden email]" <[hidden email]>, "
> [hidden email]" <[hidden email]>
> Date: Tue, 9 Apr 2019 00:29:29 +0000
> Subject: Re: Charles Winston's chord-semantics GSOC work (issue 568650043
> by [hidden email])
>
>
> On 4/8/19, 1:59 PM, "[hidden email]" <[hidden email]>
> wrote:
>
>     On 2019/04/08 18:47:13, lilypond-pkx wrote:
>     > Are we sure all the reg tests are OK (see tracker for download link)?
>
>     > For example
>
>     > regression/chord-name-major7.ly
>
>     > This looks completely broken with this patch
>
> Interesting question.  The semantics that Charles coded says that c:maj7
> is the way to indicate the C major 7 semantics.  This regtest had c:7+,
> which gives the same pitches as c:maj7, but has a different semantic
> spelling.  In my opinion, c:7+ should probably be named C#7, not C
> triangle.  Of course, the code is broken because it loses the alteration on
> the extension (but not the addition).
>

I would strongly disagree that a Cmaj7 chord should be named C#7.

From a chord symbol standpoint, no one uses #7 to indicate a maj7 chord.
The vast majority of chord symbol naming conventions use either the
triangle, M, Maj, or maj to indicate a major 7th chord.

So, I'd suggest we pick one of those.  I'm partial to the triangle, but
that's probably not the most common.

What I would suggest is that, whichever one is chosen, it is done so in
accordance with the symbols for minor, diminished and augmented.
So, for major / minor / half-diminished / diminished / augmented use one of
these sets:

    triangle / minus / null / circle / plus
    maj / min / min7b5 / dim / aug

I understand that in the lily syntax, using c:7+ makes mathematical sense,
since following chord naming convention, the "7" refers to dominant 7, or
the b7, and we are interested in saying that it is one semitone higher than
that, and this is a reasonable shorthand.

But we should not inflict this shorthand on the printed chord symbols, nor
on the semantic representation of them.

Musically speaking, we are not lowering then raising the 7th--we're simply
using the actual 7th degree, as is.
Semantically, it is moreso "natural 7" than "#7".



Thanks,

Elaine Alt
415 . 341 .4954                                           "*Confusion is
highly underrated*"
[hidden email]
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Charles Winston's chord-semantics GSOC work

Carl Sorensen-3


On 4/8/19, 7:41 PM, "lilypond-devel on behalf of Flaming Hakama by Elaine" <lilypond-devel-bounces+c_sorensen=[hidden email] on behalf of [hidden email]> wrote:

   
    I understand that in the lily syntax, using c:7+ makes mathematical sense,
    since following chord naming convention, the "7" refers to dominant 7, or
    the b7, and we are interested in saying that it is one semitone higher than
    that, and this is a reasonable shorthand.
   
    But we should not inflict this shorthand on the printed chord symbols, nor
    on the semantic representation of them.
   
    Musically speaking, we are not lowering then raising the 7th--we're simply
    using the actual 7th degree, as is.
    Semantically, it is moreso "natural 7" than "#7".

I don't disagree with you.  I'm trying to match an existing regtest.  When  majorSevenSymbol is unset, the current regtest produces C#7 when fed c:7+.  I don't know why anybody would want to unset majorSevenSymbol, but since it can be set, in can be unset.  And if it is unset, we should not produce nothing, because then c:7+ will display as C7, which is the same as c:7.  I don't think the display needs to be sensible, but it needs to be something different from C7.

I value your input and I'd like to do something that is recognizable as insane in response to insane input.

Thanks,

Carl
 

_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Charles Winston's chord-semantics GSOC work

Dan Eble
On Apr 9, 2019, at 10:43, Carl Sorensen <[hidden email]> wrote:
> majorSevenSymbol, but since it can be set, in can be unset.  And if it is unset, we should not produce nothing, because then c:7+ will display as C7, which is the same as c:7.  I don't think the display needs to be sensible, but it needs to be something different from C7.
>
> I value your input and I'd like to do something that is recognizable as insane in response to insane input.

Insanity sounds like a job for emoji!

But seriously, it would be unreasonable to demand that you do more in this patch than match the legacy behavior in this case.  If it can be improved at all, it can be improved separately.

Regards,

Dan


_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Charles Winston's chord-semantics GSOC work

Flaming Hakama by Elaine
On Tue, Apr 9, 2019 at 2:11 PM Dan Eble <[hidden email]> wrote:

> On Apr 9, 2019, at 10:43, Carl Sorensen <[hidden email]> wrote:
> > majorSevenSymbol, but since it can be set, in can be unset.  And if it
> is unset, we should not produce nothing, because then c:7+ will display as
> C7, which is the same as c:7.  I don't think the display needs to be
> sensible, but it needs to be something different from C7.
> >
> > I value your input and I'd like to do something that is recognizable as
> insane in response to insane input.
>
> Insanity sounds like a job for emoji!
>
> But seriously, it would be unreasonable to demand that you do more in this
> patch than match the legacy behavior in this case.  If it can be improved
> at all, it can be improved separately.
>
> Regards,
> —
> Dan
>

Sorry if I didn't understand this context well enough.

So, because we can set the majorSevenSymbol, therefore we must be able to
unset it?
I'm not sure I follow that logic, unless that comes part and parcel with
canonical set/unset behavior.

However, if I understand what is being proposed, if the user "unsets" it,
we apparently are going to require that it be set to something anyway ("#")?
If so, that doesn't seem like we're really "unsetting" it, but rather going
with a default.

In which case, I'm not sure why a bizarre default is better than a
reasonable default.

Also, if the user does choose to unset it (or set it to an empty string),
then aren't they saying that they want C7 and Cmaj7 to both say "C7"?
While I agree that that is a bizarre request, it seems like that is what
they would want, given that that's what they specified.

Where does the requirement come from that dominant 7 and major 7 chords
need to have different chord symbols?  Shouldn't the regtest just validate
that each chord flavor's symbol match what it is asked to show, regardless
of whether they are the same or different from each other?


Thanks,

Elaine Alt
415 . 341 .4954                                           "*Confusion is
highly underrated*"
[hidden email]
Producer ~ Composer ~ Instrumentalist ~ Educator
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
_______________________________________________
lilypond-devel mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/lilypond-devel