It’s not always easy to convince potential Finale converts … 
Dorico gets it right using a Musescore re-export (which suggests that Musescore has the best (most musical) overall XML implementation in the business…(?) )
Dorico gets it right using a Musescore re-export (which suggests that Musescore has the best (most musical) overall XML implementation in the business…(?) )
Maybe the Finale print of the score is wrong, because it can’t handle nested tuplets correctly 
Dear Fratveno,
I have the same type of problem with XML export from Dorico. I have to re-type every tuplet there is in my original Dorico file, in the target app…
I have imported tuplets, and also nested tuplets, correctly from Sibelius (see attachment). There must be something weird in Finale’s MusicXML output.
Or maybe Finale is the only program doing it right, and everybody else has misunderstood the MusicXML specification. After all, the guy who wrote the spec works for MakeMusic so he should know what it was supposed to mean 
You mean the guy who wrote the specs in such a way that at least 4 or 5 different companies can’t easily write a compatible file.
You mean the guy who wrote the specs in such a way that at least 4 or 5 different companies can’t easily write a compatible file? I know that’s not really fair. But IMO at some point somebody is going to take the lessons learned and create MusicYAML.
Try reading the spec, and make up your own mind. http://usermanuals.musicxml.com/MusicXML/MusicXML.htm#XS-MusicXML.htm%3FTocPath%3DMusicXML%2520Reference%7CScore%2520Schema%2520(XSD)%7C_____0
Actually “4 or 5” is an underestimate. So far, the actual number is more like 40 or 50.
Dorico isn’t doing anything wrong, as such, it just won’t do any “educated musical guesses”. Dorico handles XML output from Musescore notationally correct, because, it adds (as a precaution?) a tag to every note that at some point during XML development may have been deemed optional. Staffpad had (has?) a similar issue. This has been discussed previously and Daniel has commented on it several times.
My Point today is that it’s rather sad that such a simple notational feature gets slammed in the face of a potential Dorico customer… in my (contemporary art music) universe 95% still use Finale and will judge D based on how well (and easily) files can be imported…
Frank, we need the original Finale project as well as the MusicXML file to look into this. I assume that if I were to create a simple eighth note tuplet in Finale it would both be exported correctly by Finale and imported correctly by Dorico, so my assumption is that there’s something fishy about the way that particular pair of tuplets is encoded in the original Finale document.
Hi Daniel,
Files attached. (all finale generated)
test33.zip (103 KB)
MuseScore, Notion, Notation composer and Overture all interpret the finale XML correctly. (don’t have Sib* on this machine 
)
DORICO will interpret similar triplets correctly when exported from Notation composer and Musescore…
EDIT: I’m attaching an export from NC as well.
I think the clue is in here…:
<time-modification>
<actual-notes>3</actual-notes>
<normal-notes>2</normal-notes>
<normal-type>eighth</normal-type>
</time-modification>
test33-NC.zip (1.6 KB)
Yes, I can see where Dorico is getting confused. Finale excludes the element in the element under some circumstances, and Dorico is ending up inferring the wrong value when it tries to fill it in. We’ll see if we can improve this in future.
I did say that I knew I was being unfair and tried to indicate with a smiley that I was making a joke. I know its a complicated problem, and nothing makes me want to beat my head against the wall more in my day job than a Naming Standards or Taxonomy discussion. Well, almost nothing, sigh.
I do expect a YAML replacement or something at some point, and that it would take advantage of lessons learned. We don’t use XML for anything anymore. At least not for anything other than legacy apps or services that have avoided an update for whatever reason in the last decade or so. Which I think is about how old the XML 3.0 spec is. The “Hello World” example of MusicXML below is a case in point of why we changed. To display a single staff with one note, clef ,and time signature:
<?xml version="1.0" encoding="UTF-8" standalone="no"?> Music 1 0 4 4 G 2 C 4 4 whole