Hi Pavel, musicxml2ly does not like wrong timing information. The problem here is that SharpEye 2 obviously has issues with its MusicXML export. SharpEye 2 exported the wrong duration value in the backup element in the first measure. It also assigned the f (half note) to the same voice as d (whole note). musicxml2ly is right to complain. It doesn't lose any information. I find it rather awkward that MuseScore managed to render faulty markup the way it's supposed to look.
hth patrick
chords_pls.xml
Description: XML document
chords_pls_musicxml2ly-2.17.15.ly
Description: Binary data
<<inline: chords_pls_musicxml2ly_lilypond-2.17.15.png>>
On 06.07.2013, at 20:01, Pavel Roskin <pro...@gnu.org> wrote: > musicxml2ly cannot recover from some timing errors. From that point, it > stops making chords for the remainder of the score. > > This is a serious problem, as no adjustments to the broken measure made in > the musicxml2ly output would fix the consecutive output. musicxml2ly loses > information about chords. The only workaround is fixing the original > musicxml file, which is tricky. > > It the attached example, G and B in the second measure should be a chord. > Musescore shows them as a chord. But musicxml2ly generates two consecutive > whole notes. > > The problem was observed with the actual SharpEye 2 output. musicxml2ly is > from the current development version of Lilypond. > > -- > Regards, > Pavel Roskin > > <chords.xml><lilypond.png><mscore.png>_______________________________________________ > bug-lilypond mailing list > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond
_______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
