I just imported a MusicXML file into Dorico, and the result is extremely problematic.
For comparison, I imported the exact same MusicXML file into Finale and MuseScore, and both programs display the music essentially as expected.
Dorico, however, does something very strange with the opening measures.
The piece begins with three empty bars, followed by music in bar 4. In Finale and MuseScore, those four bars appear normally across the first system.
In Dorico, the first three empty bars are almost completely collapsed into a tiny space at the beginning of the system. The bar numbers 1, 2, 3, and 4 are essentially piled on top of each other, and the layout of the opening system is badly distorted. There is also a FRAME BREAK appearing there.
In addition, Dorico is laying out only one system per page, whereas the same MusicXML file produces a normal page layout in the other notation programs.
I understand that MusicXML cannot always reproduce another program’s engraving perfectly, but this goes far beyond differences in engraving or spacing. The actual measure layout of the first four bars is being interpreted in a way that makes the imported score practically unusable.
Is Dorico importing some hidden layout information from the MusicXML — such as frame/system breaks or spacing information — that causes this? If so, is there a way to tell Dorico to ignore that information during MusicXML import and simply import the musical content?
I have attached screenshots showing the Dorico result and the same file opened in another notation program for comparison.
Yes. The Preferences>MusicXML> Import options.
If you choose to import System and Frame Breaks Dorico will retain the casting off of the original and place Frame breaks and system breaks appropriately.
The collapsing bars is caused by there being no rests in the original (MusicScore has replaced them with hidden rests). If you select the first note, you will likely find the Starts Voice property has been set. Reset that and the rests will appear and the normal spacing algorithm will be applied.
To answer Derrek’s question as well: the original file actually began as a Dorico document. I exported it as MusicXML from Dorico, imported that XML into MuseScore, and then exported it again from MuseScore. The file I am now testing is that MuseScore-exported XML.
I opened it on the Mac by right-clicking the XML file in Finder and choosing Dorico from the available applications.
I will check the MusicXML import preferences and also the Starts Voice property on the first note.
What still strikes me as odd, though, is that the exact same MuseScore-exported XML opens normally in both MuseScore and Finale without any intervention. Neither program collapses the first three bars, and neither produces the one-system-per-page layout.
What I find especially disappointing is that Dorico is marketed as a program whose intelligent layout and engraving algorithms are supposed to reduce the amount of manual intervention required from the user. Yet in this case, it is the one program that requires the most intervention after importing the MusicXML file.
Fact is that Finale and MuseScore both produce a normal, usable layout immediately, while Dorico collapses the opening bars and creates a one-system-per-page layout that has to be corrected manually.
As @LAE notes, if you uncheck this option in Dorico’s Preferences > MusicXML > Import, then Dorico will ignore the explicit instruction not to print the rest.
Thank you for explaining what is happening in the XML. That does clarify the technical cause.
But this is really the point I am trying to make: as a user, I should not have to understand MusicXML code, discover that MuseScore has written print-object="no" for the rests, or know that I need to change a specific MusicXML import preference just to obtain a normal-looking score.
I am simply opening a MusicXML file. The same file opens in MuseScore and Finale with a perfectly normal, usable layout without my changing any settings or fixing anything manually.
I can understand Dorico honoring information contained in the XML. What I find difficult to understand is why honoring that information results in three empty measures being compressed almost to nothing and, separately, a one-system-per-page layout.
That is really where my disappointment with Dorico lies. One of its major strengths is supposed to be its intelligent automatic layout, reducing the need for manual intervention. Yet with this file, Dorico is the program that requires the most intervention simply to arrive at the sensible default layout that the other programs produce immediately.
As with many things, Dorico honors your settings – in this case, how closely it should follow the instructions in the XML. If you had that setting checked, then Dorico will use the rest visibility settings from the XML. I don’t think it’s necessarily fair to expect the program to be able to understand which rests should be displayed on a case by case basis.
By default, Dorico has most (all?) of these settings checked, on the assumption that you want an imported score to follow the XML as closely as possible. As others have noted, many Dorico users find that they get better results by unchecking most of those settings, in order to allow Dorico to use the raw material in the XML but apply its own formatting rules (which seems to be what you want here). If this worked the other way around, with settings unchecked by default, then users would complain that the imported XML looks nothing like the music did in the source app, so there’s no default that will please everyone.
This implies that those programs have chosen, without asking, to ignore the explicit instructions in the file, which I think is also problematic.
I don’t think this part is difficult at all. The XML says “don’t display these three rests”, so Dorico doesn’t display them; when rests are hidden in Dorico, there is nothing to provide space (this is well known).
As for the page with a single system: The default import settings say that Dorico should honor system and frame breaks in the XML. The issue here seems to be that Dorico wants one of the systems on the first page to wrap to a second system. This results in an extra system before the frame break at bar 40, and that extra system winds up on its own page. I agree that this doesn’t look good, which again is why many users prefer to uncheck most of the options in the MusicXML Import section.
You are saying, when there are four measures without rests (or hidden rests), it is okay to just cramp them into a 5-millimeter space, all 4 of them. Interesting.
the point stands that the XML standard is obviously not that standard. if 2 notation programs can export different files of the same piece. Dorico actually provides the added feature in its preferences to either fix the file or leave it be. its the users choice
But yes. It’s just the way Dorico calculates space. If there is nothing there, it has nothing to calculate. It does not guess that rests “should” be there, because perhaps there is a reason they are not there. It just starts the voice at the position where the voice starts (and the properties tell you that).
If other programs produce bad XML, Dorico should not be expected to “repair” them on vague assumptions. MuseScore on the other hand works strictly bar-by-bar and cannot accept a bar with nothing in it, so it adds the ghost rests (which are themselves indicators of errors).
