[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by addr
From: |
Carl Sorensen |
Subject: |
Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by address@hidden) |
Date: |
Wed, 3 Apr 2019 00:36:44 +0000 |
User-agent: |
Microsoft-MacOutlook/10.10.7.190210 |
On 4/2/19, 3:20 PM, "address@hidden" <address@hidden> wrote:
Hi Carl,
I appreciate you taking the time to rework this patch, does it mean
you’re intending to shepherd Charles’ work until it gets merged?
Yes.
In addition to Paul’s comments which you’ve nicely addressed, I had a
few additional ones below, on other aspects of Charles’ approach (and
taking into account that I’ve been trying to streamline some
chord-related parts of LilyPond’s codebase in the meantime).
BTW, is the end goal here to actually replace Lily’s default chord entry
mode at some point?
Replacing chord entry mode is not part of the goal for this project. The goal
is simply to capture the actual semantics entered by the user using the
standard LilyPond chord entry mode which is not based on the chord name, but
based on the chord steps and their qualities present in the chord.
Once you have the chord steps and their qualities, you should be able to derive
any naming system, as far as I can see.
As you may have noticed, I’ve dropped some chord
modes that hadn’t been working for the past 15 years anyway (namely
Banter, and jazzExceptions as well), so still referring to Ignatzek
exceptions as such whilst there are none other available has become sort
of moot. Now that we’d be having an additional `semantics’ feature, it
*could* sort of make sense to have two different systems in place
(though not in the way chord names used to be implemented). At any rate,
I’ve been trying to hunt down code duplication and clunky mechanisms
based on hardcoded stuff (e.g. "Italian" and "German" chord names and
note->string functions); I’d hope that this patch would allow further
progress in this regard but that doesn’t appear to be the case.
This patch creates a chord semantics structure and creates one namer based on
that structure. Other namers could be added.
This patch does not change any of the note-to-chord-names functions. It was
intended to not break any existing functionality.
But the chord-semantics namer should continue to work properly, even if the
note-to-chord-name functions are eliminated or changed.
I will respond to your individual comments below when I get a chance to rework
the patch, which may not be until the weekend.
Thanks,
Carl
- Charles Winston's chord-semantics GSOC work (issue 568650043 by address@hidden), v . villenave, 2019/04/02
- Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by address@hidden),
Carl Sorensen <=
- Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by address@hidden), Carl . D . Sorensen, 2019/04/06
- Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by address@hidden), v . villenave, 2019/04/08
- Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by address@hidden), pkxgnugitcl, 2019/04/08
- Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by address@hidden), thomasmorley65, 2019/04/08
- Re: Charles Winston's chord-semantics GSOC work (issue 568650043 by address@hidden), thomasmorley65, 2019/04/08