I have read that certain tuplets can spook XML conversions to the extent that everything that follows is a complete absence of notes. I can certainly attest to that. This passage (shown here as a screenshot from the piano part of the Sibelius original)
is a line that XML won’t cross, and I can’t figure out why. Here’s what happens when it’s imported into Dorico (not a single note survives after the car-crash bar; I’ve kept in one orchestral staff to show the rests) :
I’ve already done two more downloads, creating progressively more empty bars where the notes were, but I can see nothing that would unduly bother any conversion algorithm. They are standard tuplets, no nesting; there are no mismatched bars (i.e. apparent beats vs time signatures); there are no hidden or deleted rests. I could of course delete all the notes in this passage and reinput them in Dorico, but it would be useful to know what the no-no factor in material such as this might be.
Well, I haven’t found out why some tuplets would do that and others would not. There might be a pattern, but it seems it’s not an easy one, and not one Dorico could be held responsible for… If anyone has some clues, I’d be happy to learn!
Oh gosh, I never meant to imply that Dorico could be responsible - my aim was to find out what I might have been doing wrong in the Sibelius file, and correct it before export. In the end, I deleted the notes in the whole passage, and the remainder of the scene came through unscathed (hooray). Interesting, though - an appearance earlier in the scene of an identical figuration caused the conversion no problems, as, indeed, is true of most of the bar before the ‘crash’.
Perhaps someone familiar with the process could investigate this by examining the XML code directly. The problem is likely due to a rounding error caused by the conflict of base-two computer coding and the “base-3” expression of triplets. Why these two work sometimes and compound at certain points to go berserk would most likely be found in the raw XML code.
I’m no mathematician, but after looking at the XML code of the passage (having read your post, @derrek), and seeing lines such as these (speficially the 127 and 128 durations):
I wondered whether there came a point when, in a long bar of music, they added up to something impossible to convey in standard musical notation. However, even when I rebarred the offending passage from common time to 1/4, the result was exactly the same as before.
Normally the problem is caused by a particular combination of settings in the encoding of the tuplet in MusicXML that trips Dorico up; I forget the precise details, unfortunately. In general there’s nothing you can do to address this yourself, since ultimately we need to add some more heuristics to Dorico’s handling of such tuplets to try to make it more forgiving, but in the meantime the best you can do, really, is to simply delete those tuplets altogether in Sibelius and re-export the MusicXML file again, then reinput them once you’ve successfully got the rest of the music into Dorico.
Yes, Daniel, that certainly worked. It’ll be a matter of minutes to reinput the deleted bars, and I’ve got hundreds of accurately-converted bars back! Thanks.
Dear fratveno,
Last time I had those tuplet problems, I waq using… a MuseScore source file! So the problem is not Sibelius specific, but I am happy to learn that Dorico might import those better when they have time to make it more forgiving!
Hi Marc,
of course MuseScore doesn’t always work, but it seems to have some of the heuristics Daniel has mentioned. Also, it will report the errors it finds, which can (sometimes) help in pinpointing the problems. It has solved many Finale XML exports for me. E.g. triplets consisting of ‘8-16-16-8’
Well, for what it is worth, I did try to import the exported xml from MuseScore into MuseScore and the result was messy as well. So my guess is that sometimes, xml does not describe the tuplets unambiguously enough.
