Re: Rewrite chordnames - disentangle data from formatting (issue 223420043 by address@hidden)

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 4/13/15 6:06 PM, "Thomas Morley" <address@hidden> wrote:
>
>>Hi Carl,
>>
>>thanks for review.
>>
>>Pity to say my vacations ended :(
>>I'll have much less time now, so work on this will be slowed down.
>>I'll hope I can answer more thoroughly the upcoming days ...
>
> My summer time will be starting in a couple of weeks.  Maybe I can help
> with this, now you've started it.

I have to admit to not even having looked at the code yet.  But I still
want to point out one real area of operation that would be nice to
cover.

Accordion standard bass...

Basically, they lean towards being alternating chord accompaniment:

\clef bass \time 3/4 c <c' e' g'> q | g q q | g <f' g' b'> q | d q q

Namely, a pattern of alternating bass notes and chords, with the chord
inversions determined by picking all the notes from a fixed octave.  The
chord repertoire is x (major), x:m (minor), x:7^5 (major seventh missing
the fifth) and x:dim7^5 (full diminuished missing the fifth), all of
those picking an inversion in a single octave.  Chords get additionally
_labelled_ in the score (accordion players are not too good at actually
reading anything but the rhythm in bass clef) as x, xm, x7, and xv (the
latter being the German naming; it may be xdim in other languages),
while the bass notes are marked with uppercase letters.  There may be
_combined_ chords by pressing more than one button: for example, a:m7
can be represented as "c+am", and a:m6 can be represented as "am+av".

So we have, basically, an inversion-ignoring chord pattern recognition
problem, in a similar vein as guitar chord diagrams have a mostly
inversion-ignoring chord pattern recognition problem.

So it would be nice to have the chord recognition, the naming
(upper/lowercase), particular pattern recognition/exceptions all sort of
independent so that one may plug them together in different manners.

-- 
David Kastrup