mari+lilyp...@mailbox.org writes: >> On 2/9/20 1:49 PM, David Kastrup wrote: >>> mari+lilyp...@mailbox.org writes: >>> >>>> when converting a mxl file with "musicxml2ly --language=deutsch" the >>>> note "beses" is converted to "bes". Lilypond gives an error at this >>>> notename with \language "deutsch", because the correct german notename >>>> for "double flat b" is "heses". This happens with all musicxml2ly >>>> versions at least from 2.18.2 to 2.21.0. >>> >>> Just trying to fix it, but I find the following in >>> scm/define-note-names.ly in the German section: >>> >>> (heses . ,(ly:make-pitch -1 6 DOUBLE-FLAT)) >>> (heseh . ,(ly:make-pitch -1 6 THREE-Q-FLAT)) >>> (b . ,(ly:make-pitch -1 6 FLAT)) >>> (beh . ,(ly:make-pitch -1 6 SEMI-FLAT)) >>> (h . ,(ly:make-pitch -1 6 NATURAL)) >>> (hih . ,(ly:make-pitch -1 6 SEMI-SHARP)) >>> (his . ,(ly:make-pitch -1 6 SHARP)) >>> (hisih . ,(ly:make-pitch -1 6 THREE-Q-SHARP)) >>> (hisis . ,(ly:make-pitch -1 6 DOUBLE-SHARP)) >>> >>> That looks almost like something I could work with, except for beh . >>> For all other note names, the suffix -eh indicates _lowering_ by a >>> quarter note, whereas beh _raises_ b by a quarternote. Shouldn't it >>> rather be heh , making b the _only_ exception? > > At least the output of musicxml2ly should be consistent with lilypond > and should not not give an error message when compiling. > > Here the german Wikipedia for "double flat b": > https://de.wikipedia.org/wiki/Doppel-b
That is all very well, but making musicxml2ly agree with LilyPond here makes mostly sense when we are reasonably sure that LilyPond will not need to get changed again soon. So even while I understand that you are not interested in getting quarternotes working or consistent as well, I don't think it makes sense to not cater for consistency here too while I am touching the code. Since the interest on the bug list is limited for the quarternote naming problem in German, I am including the developer list here. I don't think the discussion will be so long that adding two separate fixes will prove necessary. -- David Kastrup My replies have a tendency to cause friction. To help mitigating damage, feel free to forward problematic posts to me adding a subject like "timeout 1d" (for a suggested timeout of 1 day) or "offensive". _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
