Just a thought. Have you tried using MIDI rather than musicXML to transfer your notes? I appreciate it won’t bring across your annotations, but you can re-quantize selections to tidy up notation.
No no no there’s like 100 bars of 2+3+2+2 in this piece. Also when you make it ordinary 9/8 in finale it loses the groupings and even turns quaver note plus quaver rest into crotchet.
Obviously it’s an error in Finale.
But one can work around the error despite these issue to a degree in Finale, but now…
And there’s maybe hundreds of scores (out of thousands that I have as musx files) where I’ve used this technique to make it easier to read for instrumentalists.
And I don’t even know which ones are which, really.
I just want to make sure you know that the beam groups and tie groupings can be directly affected by meters and settings in Dorico.
But before you get to that wonderful world, we need to solve this 1-EDU problem. I don’t know what else to suggest. Anyone?
midi loses an awful lot of information, nearly everything that makes music music really, and can you imagine what it would be like to go through an orchestral score and have to put everything back in? - all the ties, the crescendos, the dynamics, the lyrics, the tempo indications and italian terms, any text blocks.
I have literally thousands of musical scores in musx format. Countless numbers of them in which I have used this technique for grouping quavers or semiquavers - it’s far quicker really than manually grouping each bar individually.
Proverbs 25:20
It has all the hallmarks of a rounding error - an added fraction here, a slightly smaller fraction here - my theory is that Finale uses edu’s in the time signature field but is using some different number of subdivisions, not divisible in whole numbers with that used in mxl files (edu’s are 1024 edu’s per crotchet.) Most probably this is a feature of mxl files which maybe at the highest resolution are triplets of some sort, so every now and then the rounding error builds up and causes a problem.
Yes. I am aware. We are all just trying to provide help for you here, with a problem you acknowledge stems from Finale.
If a midi import creates the correct notation, then perhaps you could import the notes separately from the text and combine them?
Alternatively, what happens if you take the mess the xml import produced and try to re-quantise it (You can make a selection and use Edit>Requantize). Does that improve matters?
I understand that everyone is trying to help - but it wouldn’t help either for me to be dishonest about whether a solution is viable or not considering the situation. You understand this is time sensitive as well - I have projects on the go and people waiting for scores - and will have to upgrade to Mac OS Sequoia at some point because of the other software I’m using - at which point Finale is no longer supported.
Indeed, Finale is recommending Dorico as the solution to the problem, which is that Finale are closing down their software, software that I have now used for around thirty five years. I have thousands of computer files in finale format, and many other people do as well – I’m sure I’m not the only one encountering this glitch. Dorico is very generously providing a discount for Finale members moving across- and God bless them for that generosity - but I guess this still comes with some kind of obligation to make it work for us.
Okay - is Edit-Requantize a thing in Dorico? I’ll try it later today when I’m at my desktop computer, on which I’ve installed Dorico. Maybe that will do it.
Will it preserve the quaver groupings however?.. Next chapter coming soon! I’ll update once I’ve tried this.
1 Like
We are all in unknown territory here. I’m afraid your time constraints are your concern - not ours.
If time is an issue - it would be stupid not to continue to use Finale.
Have you sent your Finale file to Finale tech support? they are still there, they can analyze and advise, they know their coding.
Yes I have, just now.
I’m actually quite glad that I tried converting this file first up - it means I am already aware of this potential issue with a vast number of files - and it really has to be solved before other people start porting everything across from Finale to Dorico
I don’t have Sibelius unfortunately otherwise I’d try importing it to Sibelius and see if it does any better.
1 Like
Someone here might be able to import it for you through Sibelius.
Another idea, if this is really crucially important, is to hire a few music students (perhaps familiar with both) and they can help with your conversions … all while Finale tech support are available (for 10 months isn’t it?)
Personally I only have hundreds of Finale files and they are not as important as yours, I was using the Finale app on my iPad and preparing charts for there, then they discontinued it also. At least PDFs exist.
Best wishes, hope Finale Tech support are able to help.
thank you God bless
1 Like
I don’t know if this helps you, but when I import your file into Sibelius, it opens mostly correct, except shows the wrong time signature, but it’s basically a match for what is in Finale. If I export from there via the Dolet add-on to MusicXML again and bring that into Dorico, it is also correct (aside from the time signature).
I dug through the MusicXML you exported from Finale and found weirdness in Bar 15 of the Viola part only. It was causing the issues with the rests in Dorico (which also caused a beat to be added to the bar for some reason)
The original lines were this (starting line 23318 of the MusicXML that you uploaded):
<measure number="15" width="282">
<note default-x="26">
<pitch>
<step>E</step>
<octave>4</octave>
</pitch>
<duration>384</duration>
<voice>1</voice>
<type>quarter</type>
<dot/>
<accidental>natural</accidental>
<stem default-y="-44.5">down</stem>
</note>
<note default-x="114">
<pitch>
<step>E</step>
<alter>-1</alter>
<octave>4</octave>
</pitch>
<duration>767</duration>
<voice>1</voice>
<accidental>flat</accidental>
<stem default-y="-44.5">down</stem>
</note>
<note default-x="1789568817">
<rest/>
<duration>1</duration>
<voice>1</voice>
<type>1024th</type>
</note>
</measure>
As you can see, in the viola part in bar 15, after a normal dotted quarter note E with duration 384, there is a note Eb with no type with duration 767, one tiny duration short of completing the bar, followed by a 1024th rest with duration 1 to complete the bar.
When I manually edit the musicXML to remove the 1024th rest, and increase the duration of the preceding note to 768 as below, the MusicXML imports properly into Dorico without the problems in measure 15:
<measure number="15" width="282">
<note default-x="26">
<pitch>
<step>E</step>
<octave>4</octave>
</pitch>
<duration>384</duration>
<voice>1</voice>
<type>quarter</type>
<dot/>
<accidental>natural</accidental>
<stem default-y="-44.5">down</stem>
</note>
<note default-x="114">
<pitch>
<step>E</step>
<alter>-1</alter>
<octave>4</octave>
</pitch>
<duration>768</duration>
<voice>1</voice>
<accidental>flat</accidental>
<stem default-y="-44.5">down</stem>
</note>
</measure>
In this case of m. 15 it might be some kind of bug in the Dorico importer involving very tiny note/rest lengths, because I would expect a note with duration 767 followed by a rest with duration 1 to import basically the same as a note of duration 768 (either should add up to duration 1152 of the entire bar).
But after making that change, bar 15 shows up like it should, instead of having that mess of rests at the end. The whole file looks fine then, actually.
2 Likes
Thank you so much for this! That’s a great start.
At least I know there’s a way forward. Thank you thank you.
I guess at some point some Dorico programmers might read this post. Maybe there’s a possibility Dorico could look into solving this potential problem on xml imports? It would commend their software to every Finale user who is being forced to change over and save us from having to buy both Sibelius and Dorico; in $AU that’s quite a lot of money (over $600)! I’m a composer I’m not made of cash! I already have a Waves subscription, a Reason subscription, an Adobe subscription, a Microsoft subscription, an iTunes match subscription, an iCloud subscription, etc etc.
Or maybe even Finale could fix whatever is causing this problem, as a final gesture of goodwill before we all change over? Either would be great ! Cheers.
Deleting the contents of bar 15 from the viola part in Finale before exporting the MusicXML also appears to fix it and it works - just a matter of entering those two notes back in after opening it in Dorico.
So even if you didn’t know where the problem was happening, the crazy ties in bar 15 of the viola on initial import attempt into Dorico would give you a clue and then you could delete the contents of that bar of the viola in Finale and try the export again.
Wondering if you have tried importing into Musescore and from there into Dorico?
That would possibly work because when I tested the import of the original XML into the latest MuseScore, MuseScore silently deletes the weird E-flat in the viola that is the problem, so probably re-exporting and importing into Dorico might work. However MuseScore doesn’t seem to be able to import the composite time signatures (it just shows 1/4 instead of 1/4+3/8+1/4+1/4, same as Sibelius) while, of the three programs, only Dorico imports the 1/4+3/8+1/4+1/4 correctly. So you could end up with other problems caused by this data loss.
1 Like