let’s face it, a lot of people have Sibelius projects they would like to port to Dorico.
MusicXML is problematic.
Sibelius plugins such as Dolet can maybe do a better job, but what about writing a specific Dorico exporter plugin for Sibelius? Then Steinberg could maintain control and quality of the output.
I don’t think this would be practical on any level, I’m afraid. Sorry to pour cold water on your idea.
I guess you’d know more than anyone.
I just tried dolet (didn’t know it was now owned by the Finale guys), and whilst it was a lot better, there were still quite a few problems exporting from Sibelius to Dorico via MusicXML.
Lots of cases where hairpins were swapped for dynamics, or seemingly coming from other parts of the score. It makes me wonder if SIbelius internal format is a mess.
What about some other intermediate format, rather than into Dorico binary format, e.g. something better than MusicXML, or a new flavour of it which isn’t so broken. Dolet on Sib is only MXML 3.0.
Looks like all Sib plugins are “open source” so maybe I will try hacking the Dolet one, or at least try and see where the errors are coming in.
Not all. Some are paid for.
You could try Bob Zawalich, who knows more about plugins for Sibelius than anyone.
Interestingly I just tried uploading my XML file to soundslice.com.
It doesn’t show the munged dynamics and hairpins that Dorico does, so that kinda implicates Dorico as the culprit.
Have you experimented with Dorico’s Preferences for MusicXML import?
Do you have your Layout Options to show hairpins as hairpins, by default, not cresc./dim. text? (Dorico treats hairpins and cresc./dim. text as the same thing, unlike Sibelius. Makes it easy to change your mind about which you want, and for that matter, easy to show text in one layout and hairpins in another, but you do need to get your head around it).
I told you about MakeMusic buying out Dolet two weeks ago, the last time you posted on this subject, here: A philosophical problem - stripping unrecognised annotations from musicXML import - Dorico - Steinberg Forums
No, but I don’t think there’s an option in there to randomly move sections of dynamic around, or delete them altogether. Not all the breakages were substitution of hairpins for dynamic markings, there were plenty of places where large number of consecutive dynamics for a part were just gone (or moved to another location a long way away). Many cases where dim became cresc, where f became p etc etc. Random (seemingly).
I think this is most likely a bug, and I’m saying that with 23 years of commercial software development experience.
I looked over the MusicXML spec (in as much as there is one - only the xsd files “the documentation is the code”). There are some “questionable” design decisions made there, the one that stands out the most for me so far is the <backup…/> element. Like having to rewind the tape (the correct amount) to play in another voice in the same measure. Notes are not indexed in terms of position in a measure, and I suppose other items aren’t either. So if the durations of the notes don’t add up to a measure, I’m not sure what should happen. There seems to be a distinct lack of explanatory prose in the “spec”. The musicXML files don’t seem to use CDATA for multiline text (which therefore will treat your whitespace as semantically irrelevant, as per (IMO broken) XML specs).
Durations of things seems a bit hacky as well. Find a large common multiple of all the things you may need to multiply in order to evenly divide later. So a crotchet has a duration of 768. Must cause havoc for tuplets of unusual or prime numbers of notes, they couldn’t end up with equal durations. They could have kept to the 2 number system (numerator and denominator), or specified note durations the same way they are notated.
JSON would have been a much better base format than XML, but it didn’t exist then back in the crazy days of using XML for absolutely everything even though it fails protocol design 101 (try nesting CDATA). Easy for me to say I know.