Re: Musicxml2ly: Fix incorrect conversion of Minor Chords (issue 305700043 by address@hidden)

[David Kastrup]

Johan Vromans <address@hidden> writes:

>> > The bottom line is: What is required in chord c:blah so that .NN can  
>> > be added as a pure addition. It is unfortunate that c:.13 is invalid  
>> > syntax.
>
> Since MusicXML additions are pure additions, would it be safe to turn these
> into (addNN)?
>
> E.g. C + 13 => c:(add13)

Uh, we don't have syntax like that as _input_ syntax?  You mean, allow
c:add13 here?

> Even though that will turn a friendly C13 (user input) via C + 7 + 9 + 11 +
> 13 (MusicXML) into an ugly c:(add7)(add9)(add11)(add13) (LilyPond)...
>
> Otherwise, I'd go for the origional idea of parsing for a preceding digit,
> optionally followed by '+' or '-' (if that would cover all).

Frankly, the .xxx syntax essentially already means "add".  I happen to
be partial to creating a "major" modifier.

Here is how the Italian accordionists do it:

Bonus points for recognizing the fragment...

Here is a somewhat expansive description:
<http://www.planet-accordion.com/en/the-standard-basses-structure-and-notation/>

>From the various notations, I find that "M" does fit LilyPond's existing
schemes best as a "major" modifier.

I am not convinced at how the following are rendered.  Particularly c:m5
seems nonsensical, but I'm not too enthusiastic about the others either.

\chordmode { c:dim5 c:m5 c:5 c:maj5 }

Maybe just kill the special effect of "5" whenever it is not first?
There is also the possibility of "whenever it is not alone", but I am
less convinced about what that would do to c:5.6 and similar.

-- 
David Kastrup