On 12.01.2014, at 13:29, James <pkx1...@gmail.com> wrote: > On 12/01/14 07:57, pls wrote: >> On 12.01.2014, at 03:52, Andre Soares<andregs...@gmail.com> wrote: >> >>>> >>I'm not top posting. >>> >Hello! >>> >I have this example file.xml: >>> ><score-partwise> >>> > <part-list> >>> > <score-part id="1"/> >>> > </part-list> >>> > <part id="1"> >>> > <measure> >>> > <note> >>> > <pitch> >>> > <step>C</step> >>> > <octave>4</octave> >>> > </pitch> >>> > <duration>2</duration> >>> > <beam>begin</beam> >>> > </note> >>> > <note> >>> > <pitch> >>> > <step>E</step> >>> > <octave>4</octave> >>> > </pitch> >>> > <duration>2</duration> >>> > <beam>end</beam> >>> > <notations> >>> > <articulations> >>> > <breath-mark/> >>> > </articulations> >>> > </notations> >>> > </note> >>> > </measure> >>> > </part> >>> ></score-partwise> >>> > >>> > >>> >When i run "musicxml2ly file.xml" i got file.ly with something like this: >>> >% file.ly begin >>> >\version "2.18.0" >>> >... >>> >c2 [ e2 \breathe ] >>> >... >>> >% file.ly end >>> > >>> > >>> >Notice that "\breathe" is before "]" causing an error when I run "lilypond >>> >file.ly": >>> >teste.ly:14:22: error: syntax error, unexpected EVENT_IDENTIFIER >>> > c2 [ e2 \breathe >>> > ] } >>> > >>> >Sorry for the long report. It was the tinyest example i could build. >>> >I'm just willing to help lilypond community, which I love! >> Hi Andre, >> >> thanks for the report! It definitely is a bug. > > http://code.google.com/p/lilypond/issues/detail?id=3800 > > Although I am not sure what the proper title should be - I made an educated > guess > > 'MusicXML beaming information causes LP file compilation errors with some > markup scripts' Hm, it's rather a conversion error of expressive marks in general in combination with manual beaming (see file attached). musicxml2ly places breath marks, dynamics, fermatas, etc. _within_ manual beam brackets instead of _after_ the right square bracket. This causes a fatal error during compilation.
Interestingly LilyPond generates a warning during compilation even when expression marks are placed after the closing square bracket. The result looks fine, though. This seems to be a different issue. hth patrick
expressive_marks_and_manual_beams.xml
Description: XML document
_______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
