after xml import: bar is too large

After musicXML import I got a 5/8 bar with 8/8 + a dotted 16th. What I can do to solve the problem?

Best, Maximilian
Bildschirmfoto 2017-01-19 um 13.54.18.png

This kind of problem is quite tricky to sort out at the moment, unfortunately, because you will need to recreate the time signature at the start of the 5/8 bar, and then you may need to manually move all of the material in all subsequent voices using Insert mode, which will unfortunately not move things like other barlines and time signatures, since Insert mode currently only affects items in a single voice, and things like barlines and time signatures are not assigned to specific voices, but rather to a more global stream. We do plan to extend the capabilities of Insert mode to span all voices and items in the global stream in due course.

Thank you for your answer. Unfortunately I need about 5 hours to correct the problem. Moving tuplets and polyphony often didn’t work as expected. It worked better to copy and paste the bars separate to the right position. I not able to say what are the reasons for this problems: bugs in the music xml, bugs in Dorico or mistakes that I made.

I’m getting this problem as well. Attached xml file was created in Cubase 8.5, with all notes quantised and tidied-up for score purposes. The nonsense starts in bar 18, which is a quaver too long in piano part despite no time sig change. It gets worse from 23; the piano part ends up a crotchet+demisemiquaver too long (out of sync with cello) by the end.
Currently xml is of course the only way to get things from Cubase to Dorico, so this is rather serious.
[MacPro 2013, OSX 10.12.2]
Vc Bagatelle (11.6 KB)

Thanks for submitting your problem file. I’ve asked our resident MusicXML expert to look at this and we’ll report back as to what’s going on as soon as we can.

Thanks, Daniel. By the way, here is what it ought to look like (pdf exported from Dorico after some hours of painful cut and paste).
Bagatelle (469 KB)

We’ve taken a look at the MusicXML file and the problem is caused by a bug in Cubase’s MusicXML export when dealing with tuplets containing rests. The Cubase team are working on a fix for this problem, which will hopefully be included in a maintenance release for Cubase 9 in the relatively near future. I’m afraid I don’t believe there are any plans for any further maintenance updates to Cubase 8.5, but I will check with our product planning team about that.

For what it’s worth, I’ve had no problems importing MusicXML files generated by Finale into Dorico. I’ve had a few issues importing the same files into Cubase though - pickup bars in particular can cause confusion.

Thanks again Daniel, that’s a good start. I was going to upgrade to Cubase 9 anyway!

Unfortunately, I have another example of the same thing that involves no tuplets at all. The attached pdf (exported from Cubase) shows what the first couple of pages should look like. The keyboard player moves from piano to Indian harmonium at bar 11, after the opening solo. The xml however shows a complete dog’s breakfast; strings and harmonium come in several bars early, but bar lengths have already been comprehensively mashed even during the piano solo.

This is possibly a Cubase problem again; if so, the Cubase team might like to have a look at this whilst they’re investigating the other stuff? (29.7 KB) (1.39 MB)

Thanks, we’ll take a look at these and report back.

The problem in this MusicXML file is that when you set the Cubase score editor to hide empty staves, the exported MusicXML ends up in a bit of a parlous state (e.g. no rests are exported). I suggest you set the score editor not to hide any staves, and then export the MusicXML file again, and hopefully things will work out slightly better.

OK, I can confirm that when I unhide the staves, everything now reads correctly. But there is still an issue with double dots; either Dorico or Cubase isn’t translating them properly. If in Cubase you write a crotchet tied to a dotted quaver, followed by a semiquaver (= double-dotted crotchet then semiquaver), somewhere along the line the double-dot is truncated to a single dot, and the following semiquaver now happens a semiquaver early. But I’ll assume that this is a Cubase problem! (can supply xml example but it’s probably quicker just to test it yourself directly).

I suspect this is indeed a Cubase problem, which we’ll look into and report to the relevant developers if we discover a problem.

OK, thanks very much Daniel. Sorry to have kept up the thread so long, but (failing direct import of Cubase files) clean xml transfer is rather crucial!

Just to confirm that we have reproduced the problem with double dotted notes not being exported correctly from Cubase and have asked the relevant developers to take a look. I can’t promise they will be able to implement a fix in a specific timescale, but there have been a number of fixes to Cubase’s MusicXML export made recently, and hopefully they will be able to squeeze in a few more.

Test (221 KB)
.Just been testing xml export/import with Cubase 9.0.10 and Dorico 1.0.30. Still no joy, I’m afraid.

  1. Cubase 9 now instantly crashes when I try to export as xml the same pre-existing files that happily exported (though incorrectly) as xml in 8.5. I carefully cleaned these files (no plugins or vst instruments etc, no hidden staves) and resaved them. The instant crash happens with pieces for one, two and four instruments.

  2. Files newly-created in Cubase 9 will save as xml without a crash, but are still not imported correctly by Dorico. Attached is a zip archive containing a). a random-note test Cubase file (12 bars long, includes various double-dotted notes and tuplets), b). xml export of this, c). resulting Dorico import file. The Dorico file appears as truncated to 10 bars not 12; the double-dots are still ignored, the bars containing tuplets give out after the first 5-let beat (which is otherwise correct).

This is probably still a Cubase problem, but certainly affects Dorico seriously. Could you please pass this on to the Cubase folk? (I’m not getting any response from them).


[MacPro 2013 6-core 3.5, 16GB RAM, OSX 10.12.3, Apogee Ensemble]

Yes, I will make sure this gets passed on to the relevant people in the Cubase engineering team.