I think I discovered a bug with musicxml import (details below) and prepared files for showcasing the problem. I think they could help the dev team, in case this is a not-yet-known behaviour. Where do send those files to? Where do I report bugs?
A piano piece (made in Finale 27.2, macOS 10.15.6) has 2 layers in the right hand. The first layer is a continuum of 32nd-notes with various tuplets. The second layer is used to add downstems to selected notes of the first layer to indicate a “hidden melody”. The same tuplets are used, but rests and tuplet symbols are hidden. (See sceenshot example.)
When exporting to musicxml from Finale and importing it into Dorico 4.10 (macOS 10.15.6), Dorico stops “drawing” the music as soon as it encounters hidden rests under hidden tuplets.
This behaviour does not happen, when the rests are visible.
This is the best place to report bugs. You can attach the files here. However, I suspect that the problem here is really in what is actually encoded in the MusicXML file, rather than with what Dorico is able to do with the import. Hidden items in Finale are often not included in the MusicXML file. Please prepare a small example, just a bar or so will do, and attach it here, and we’ll take a look.
Thank, @dspreadbury , for your fast response!
I put together the Finale files and the exported musicxml and mxl files along with 3 videos. There are no Dorico files, since I assume you will test the import in Dorico (please let me know, when my assumption is wrong!)
Since all that is too big for this forum, I put it on my server:
The problem starts at measure 4, 2nd beat.
It indeed seems to be a Finale-related problem. I looked through the mxl files and discovered that Finale exports measure 4, second layer, beginning with second quarter note, with “actual-notes” set to “15” based on 32nds, when “note.print-object=‘no’”. However, when it is a visible entry, the “actual-notes” reads “3” and the note value is detected as “eighth” note.
I guess when the export is erroneous, Dorico can’t do much…
Would love to know, what you find out!
Thanks for providing this files. There’s not a lot we can do to handle the import when vital elements like tuplets are not encoded in the MusicXML file, I’m afraid.
This is unfortunately pretty common for tuplets with hidden notes in Finale exported via XML. The only solution is to delete the offending passages in Finale before exporting.
…or unhide any hidden items. Haven’t checked the documentation yet, but maybe that could be mentioned there?
Dorico documentation, or Finale documentation? If the former, that’s not really Dorico’s issue.
MusicXML originated with Finale, so they’re the ones that should fix its encoding (or whatever that’s called).
Yes, I think if you unhide any hidden tuplets, notes, rests, time signatures etc. in Finale before you export the MusicXML file, you should get better, more consistent results in Dorico.
Yes, I meant in Dorico’s docu, just like a little hint along the line of “Hint: when exporting from Finale, make sure to unhide items first to reduce potential errors.”
It is just meant as an idea to reduce questions from guys like me… nothing important though.
(I wouldn’t wait for Finale to mention such a thing or even fix it…)
But the MusicXML issue is not specific to Finale. Different problems occur with xmls from many different source programs. Should hints be supplied for each and every one of them?
@Janus As long as there are known problems, why not? Just one more great feature of Dorico’s quality.
I am new to Dorico, but getting serious now (having bought a license eventually) – meaning I don’t know, how often such questions concerning musicxml come up. Maybe you have a feeling which are the most problematic ones, or maybe you have some metrics. It depends on the Dorico team: if they see that there is enough need for such an addition to the docu, I’ sure they’ll do it; if there are only a few guys like me, the effort is probably not worth it.
I don’t know, if you belong to the Dorico team, @Janus, but if, you would know way better then I do, if this would be something that could eventually save time (for us, for the team, …).
As I mentioned above: just an idea…
There are more important issues on the agenda, though, I am pretty sure!
Thanks for all the feedback!
Because the problems exist outwith Dorico’s control. The documentation is already voluminous almost to the point of indigestibility. Why clutter it further?
No. I’m just a.n. other user. Like most others here.
A cursory search of this forum would show you.
You can tell who’s on the Team by the little Steinberg logo overlaid on their avatar, like Daniel in post #8 above.