[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Google SoC
From: |
Carl Sorensen |
Subject: |
Re: Google SoC |
Date: |
Tue, 28 Mar 2017 16:36:36 +0000 |
User-agent: |
Microsoft-MacOutlook/14.7.2.170228 |
On 3/28/17 9:06 AM, "Winston, Charles R." <address@hidden>
wrote:
>Is the main goal of this project to expand the functionality of chord
>mode, so as to allow the user to input arbitrarily complex chords? Or is
>it to develop a more powerful internal interpretation of
> chorded notes (i.e. <c e g>)? Your example of the problematic ambiguity
>in the chord <c e gis> ‹ is it C aug, E aug, or G# aug? ‹ is what makes
>me think it is probably the latter, because if the user were to enter
>into chord mode c:aug, e:aug, or gis:aug there
> would be no ambiguity.
The main goal of this project is to develop an internal representation of
chords that captures the appropriate musical semantics.
Once we have the appropriate internal representation, we can then move in
two additional directions: Strengthen/simplify the chord name output
Improve the chord mode input
But these two projects only follow the first.
As mentioned, when the user enters c:aug, e:aug, or gis:aug there is no
question in the source file. But once this is translated into a list of
pitches, the semantics are lost. So the difference is no longer reflected
in the internal representation. That's what we're trying to fix.
Hope this helps,
Carl
- Fwd: Google SoC, Jeffery Shivers, 2017/03/27
- Message not available
- Re: Google SoC,
Carl Sorensen <=
- Message not available
- Message not available
- Re: Google SoC, Carl Sorensen, 2017/03/28
- Re: Google SoC, Winston, Charles R., 2017/03/30
- Re: Google SoC, Carl Sorensen, 2017/03/29
- Re: Google SoC, Jeffery Shivers, 2017/03/29
- Re: Google SoC, Winston, Charles R., 2017/03/30
- Re: Google SoC, Jeffery Shivers, 2017/03/30
- Re: Google SoC, Carl Sorensen, 2017/03/30
- Re: Google SoC, Winston, Charles R., 2017/03/30