Dorico 5, but still NO FERMATAS in MusicXMl export!

Great job from the amazing Dorico team, as usual, with the D5 release!

The Dorico 5 Version history lists things as system formatting, sizes and margins etc. now included in the MusicXml export - even diamond noteheads…

BUT - still in this brand new version - basic notation elements as FERMATAS ARE NOT! :scream: Also other basic stuff as system text etc. still missing. This is so confusing and frustrating! Yet another paid major version upgrade without this major issue solved… Still having to resort to MuseScore for everyday music notation editing…!

Dear Dorico team! Give us a quick update with usable MusicXml export very soon.

Best! / Jonas

I was really hoping for system text. At least they now support system and page breaks. In the live youtube session, in the chat Daniel Spreadbury did say that they planned to do more with musicXML “soonish” (whatever that means). We all really do need usable MusicXML export.

1 Like

All software producers favour import features over export. And for musicXML it is perfectly understandable for a notation program to want to read more features from other notation programs than it might send back.

Not for me it’s not. If you’re going to implement any sort of feature (like musicxml export), the basics should be there. System text is certainly a basic. (Considering lyrics export works, even more so). Fermatas, maybe not.

it is perfectly understandable

Maybe it was 5 years ago, but not now, and not when regarding that Dorico is a pro level program with paid yearly updates.

I’m involved in a large collaborative project with lots of MusicXML producers. Content is produced using Finale, Sibelius, MuseScore and Dorico. The program that currently produces the least flawed xml-files is MuseScore. (Both Finale and Sibelius files are causing problems with “semantically buggy” output.)

Dorico sadly stands out as the program that just doesn’t do the very basics.

I agree that Dorico’s MusicXML export is still far away from where it needs to be. We will definitely spend some more time in this area as soon as we can, and within the 5.x cycle. If we don’t, you can come around to my house and bop me on the nose.


Now THIS is commitment to customer satisfaction!

1 Like

@dspreadbury, I’m already planning a roundtrip with cakes :birthday: and spirits :champagne: to you and your great team, for creating such an amazing piece of software with so much talent and passion for music baked into it… :slight_smile:

Keep it up!
Looking forward to soon to come updates :wink:


Have you ensured that MuseScore’s XML is actually the ‘least flawed’ – rather than the importers of the receiving apps being more forgiving?

As the ‘makers’ of MusicXML, one would expect Finale’s XML to be the ideal embodiment of the standard. I hope you’re taking them to task over it, if that’s not the case.

1 Like

For my purposes, and after testing Sibelius, Finale and Dorico, MuseScore does seem to have the best implementation and certainly the widest number of elements that are exported.
Overall I’m happy with the update, I was just hoping for system text musicxml export in this version.

@benwiggy When talking about “semantically buggy” xml output, I mean such things as exporting bar pauses in a 3/4 context as “whole not rests” (not as actual “bar rests”), or forgetting to include the tag to mark the closing of a tied note etc. (This kind of “bugs” are more common in Fin- an Sib-exported scores than in MS-exported ones, to my experience.)

When imported into a music notation program, these “bugs” are typically swallowed and and interpreted correctly by a forgiving and intelligent importer. But if you try to use this kind of “semantically buggy” xml in another context, for example using a “non-forgiving” rendering engine as Verovio, or parsing the xml for other uses, it causes problems.