MusicXML and random pagebreaks
There is a very annoying bug when you export a MusicXML file, it will place random pagebreaks all over your score.
I have tried to put in the page breaks and line breaks manually in the places where they a meant to be but it does not matter what I do Musescore seems to ignore it and do what it wants when it comes to pagebreaks when it comes to MusicXML files.
Also it will put the page break any where, even in the middle of a staff.
Comments
Posting a sample file and steps to reproduce would be necessary to figure out what you are talking abut here. Also say what OS and what MuseScore version you are using. I've never experienced what you seem to be describing. When using 1.2, breaks are added every there is is an visible break - whether you added it manually or that's just where the line breaks. That's standard MusicXML behavior as far as I know. In 2.0, there are options in Edit / Preferences / Export to let you control more aspects of the exported layout. So if you're talking about 2.0, please also specify what options you have set in that dialog, along with posting a sample score and steps to reproduce.
Reminder: like Marc said: please supply the required information or the issue cannot be fixed. With MuseScore 2.0 expected soon, a quick reply is necessary.
Hi 3djake
For future reports, could you read this ?
Thanks :).
This happens consistently to me with the latest nightly on OSX 10.8.4 (MuseScoreNightly-2013-09-01-1422-5ba3947.dmg).
I've created an easy-to-reproduce test case.
Here's the input (a MuseScore file (created with v1.3):_
http://viz.runningwithdata.com/haydn/017_4m1.mscz
Convert to MusicXML with the following command line:
> /Applications/MuseScoreNightly.app/Contents/MacOS/mscore 017_4m1.mscz -o 017_4m1.mxl
The resulting .mxl file is here:
http://viz.runningwithdata.com/haydn/017_4m1.mxl
Open it in MuseScore (latest nightly).
Note the superfluous page breaks starting at page 8.
I did get some errors/stdout spew while the conversion was going on. I've captured it here:
http://viz.runningwithdata.com/haydn/stdout.txt
It's mainly an import problem.
MuseScore tries to put measure 77 to 85 on the same line but can't with its default spacing (MusicXML doesn't have this concept). So it puts measure 85 on its own and honors the line break at the end of it. Then there is no more place in the page and it puts the next system on the next page, and honors the page break.
A quick workaround, go to Style -> General -> Measure -> Spacing and change it to 1.10.
MusicXML import could do smart things to verify that we don't jump to a new system if there is no explicit line breaks in the MusicXML file but some MusicXML don't have line break at all... We could also consider the measure width if available, currently it's ignored.
If I understand your response properly, what you are saying is that there isn't an issue with the underlying musicXML, there's an issue with how it's displayed?
But this only seems to happen to musicXML that has been exported from MuseScore. I've opened several other MusicXML files from other sources in MuseScore without any problem. For example:
http://viz.runningwithdata.com/haydn/074_1m1.mxl
Is this difference due to the fact that MuseScore exports line/page breaks when it writes MusicXML? If so, is there a way to turn off the page breaks? (or post-process the xml to remove them).
Also for the " Style -> General -> Measure -> Spacing = 1.10" hack, is there a way to do that from the command line? I'm batch-processing ...
Thanks!
I think what he's saying is, this sort of problem will happen sometimes and is pretty much unavoidable. MusicXML files can contain info that say "insert break here", but that doesn't mean software can't insert other breaks in other places. What if the input files contained 100 measures in a row with no breaks? Clearly, MuseScore would need to insert some. And then what if the input file contained its own break right after the spot where MuseScore decided to insert one? You'll get two breaks in a row. Well, that's pretty much what happened here. Apparently the original score had slightly tighter spacing or smaller staves and was able to fit more music per page than MuseScore can with its default import settings. So you will need to override those spacing and staff size settings to get as much per page as the original had. That's just kind of a fact of life with MusicXML import.
[accidental double post]
From what you're saying, it seems like what I want is an option not to export page/line breaks in my MusicXML, so when MuseScore opens it, it can do whatever nifty flowing algorithm it wants to make page and line breaks maximally pretty and fit the current page/spacing options.
Is such a thing possible?
Yes, under edit / preferences / export in the development builds, there is an option to control export of breaks, and a corresponding option to control breaks on import as well..
Ok. So, I set Preferences | Export | MusicXML | Export manually added system and page breaks only (This seems like it should be the default, maybe?), and this does indeed take effect from the command line for conversion. Great!
However, there is still a lot of stdout spew, and it makes me worry that there might be errors in what I exported. Looking at the output (http://viz.runningwithdata.com/haydn/stdout.txt) it is not particularly illuminating in figuring out what might have gone wrong and where to check. There are a lot of lines like "pitch2xml problem: alter 11 step 3(line 4) octave 3 clef 11(offset -6)" which sound like they may be resulting in mis-exported pitches. But I don't know in what bar or voice this might be happening in to track the error down. Do these messages indicate errors that I should worry about? How do I track down the locations in the score that the error messages refer to?
Thanks,
Jason
File 074_1m1.mxl imports without obvious layout problems because it basically does not contains breaks, leaving MuseScore free to layout it according to its current settings. Actually there is one line break in the file: at measure 154.
The pitch2xml error message when exporting file 017_4m1 are harmless (debug messages that still have to removed). They appear when exporting Cb and B#. Most are Cb's found in measure 66. The exported MusicXML is correct. Unfortunately, there is no easy way to find out what is causing these messages.
Thanks, Leon.
This issue seems to have been fixed long time ago. I close it. Reopen if needed.