< Back to IRCAM Forum

Xml and Dorico

OpenMusic
#1

Hello,

There was a discussion about xml export and Dorico here some time ago. I have so far not managed to open xml from OM with Dorico, it always crashes (OM 6.12 and latest Dorico version). I get this response from Dorico’s support: “The reason Dorico is crashing, is because the MusicXML file is malformed.”
Still it opens in Finale and Sibelius without a problem, because they have support for this ‘malformed’ format. I’m not sure what it means, and I’m not doing any coding of musicxml, could one create a xml approved by Dorico while keeping all eight-tone accidentals and rhythmic notation (tuplets and nested tuplets)? Could it be done with some adjustments to the existing export or would it have to be redesigned from scratch?
I attach the file that crashed Dorico and a screenshot.

Best
Ruben

OMexportRubenScreenshot.tiff (234 KB)

#2

Hello Ruben, I tested pitch only voice object now as you with Dorico 1.1 and OM 6.12. Your file doesn’t crash Dorico, but hang.

So I did another test. And as the message appeared in Dorico, I just clicked okay, and it opened. Then I tested a version with both pitch and more complex rhythms and the Dorico crashed. And after reopening nothing happens.

Check out the attached PDF. It seems to me that it has to do if the Voice object has a self input, or tree and chord input.

Best, Dagfinn

Test-Dorico-III.pdf (101 KB)

#3

Hello,

Thank you, maybe there are some possibilities. I should have provided more details, the Dorico team also wrote:

“Your file both uses incorrect values for the various microtonal accidentals that are outside those values specified by the schema, and also uses an invalid format to declare the durations of notes. It is definitely the responsibility of the exporting application, in this case OpenMusic, to make sure that the MusicXML files it exports at least pass the schema validation. To their credit they have fixed several of the problems.”

Which means it may be a disagreement on what’s the best syntax of a MusicXml file, and a lisp coding question. It could be tempting to try to learn the syntax Dorico wants and make my own export function in Lisp, but there may be people in here who have good solutions to this.

Best
Ruben

#4

Dear Ruben,

Since i have written this code years ago (about 10 yrs ago), i just have to add some comment here on your post:

  1. When Dorico support says the xml exported is malformed, well this is really BS :
  • Musicxml, supposed to be a standard, is not a standard when it is parsed. You noticed this yourself, (quoting) : “Still it opens in Finale and Sibelius without a problem,”
    I have been dealing with this issue getting it compatible with Finale and Sibelius. Both import parsers are really different.
    My conclusions (and not only mine…) Musicxml is not a standard at all unfortunately when it comes to be parsed.

So :

  1. For sometime now, I don’t use anymore neither Finale, neither Sibelius or Dorico, since i am a Linux user. I use Lilypond, which is really in my opinion the best actual music typesetter.

So :

  1. Solutions :
    a) use lilypond (there is a good library for exporting OM score classes you’ll find it here : http://karim.haddad.free.fr/pages/downloads.html)
    Or
    b) you are free to tweak the code which you will find in OM*/code/projects/02-musicproject/import-export/export-mxml.lisp

I am sorry i don’t have much time to spend on commercial software programs that really sucks. Feel free, " Do it yourself"!

Best
K

#5

The XML exported by OM is well-formed. It is conformant to the MusicXML 1.1 DTD (DOCTYPE score-partwise). That’s what the document states. It also conforms to version 3.0 of the DTD. The DTDs of MusicXML, however, are less strict than the schemas. The schemas introduce type specifications which the DTDs lack. It seems that the MusicXML 3.0 schemas (of 2011) were an effort to improve interoperability between applications which support MusicXML. And it seems that Dorico just supports the version 3.0 schemas.

Karim is right that MusicXML is not a standard by 100 %. Developers have to cope not only with versions which have redefined some elements without distinguishing them by a new name, but also with proprietory dialects.

@Ruben: You could try the following to adapt the exported XML to the expectations of Dorico: 1. Replace sharp-three by
three-quarters-sharp. 2. Re-arrange the fractions in elements by moving the denominator into the element under /. This is not that easy, at least it’s not a simple copy/replace. It becomes even more difficult with tuplets, because for these there should be a element containing the logical definition and a element containing the graphical representation. You could consider to quantize the score to quadratic durations. I’ve to admit that I don’t know if these manual modifications actually will help. It could indeed be easier to learn Lilypond.

@Karim: I understand that you’re tired to experimentally adapt to “de-facto standards” (or sub-standards). But it could be worth the effort to move to version 3.0 which is stable since late 2011.

#6

Hi there, my 2 cents here: sharp-tree in OM XML export is not used for 3/4th tone accidentals (three-quarters-sharp is for that) but for 7/8th.

I don’t know why the name is like that, but I don’t think this accidental is actually defined at all in the XML spec ?

That would correspod to the pitch+1’s flat-down…

#7

@Jean: Ah, my fault, this was a false match. It could rather be sharp-3 in the set of accidental values. The documentation in the schema says:

The numbered sharp and flat accidentals are superscripted versions of the accidental signs, used in Turkish folk music.
It seems that the trailing numbers are indices and do not indicate amounts. Note, by the way, that there's no sharp-4, while flat-4 exists. Numerical divisions of semitones can be expressed by a decimal type named semitones which is used in the complex type pitch. In MusicXML pitch alteration and its graphical representation are completely independent from each other.
#8

In the meantime I learned (from the “Makam” article in Wikipedia) that the superscripted numbers are so-called commas, see also https://w3c.github.io/smufl/gitbook/tables/turkish-folk-music-accidentals.html. But the use in OM seems to be different.

#9

Thank you for useful information! I would probably want to translate 3/4-sharp and 7/8-sharp to enharmonic flats on export. That’s what I would change them to anyway. I’ll study this more and also consider Lilypond.

Best
Ruben

#10

There is a new version of MusicXML 3.1 in the last version of Finale 25.4 from June 29th 2017.

Best, Dagfinn