< Back to IRCAM Forum

Rhythm error in XML export

OpenMusic
#1

Hi there ! I’ve been toying with the MusicXML export in the past days, and I’m really happy of the results. However I wanted to report a small bug in the export of rhythm. In the enclosed pdf there is a draft of a section of a string quartet. Every instrument has two staves, the upper one is the result of the MusXML export, the lower of the good old ETF export. You will notice that in some particular cases (that I underlined) the MusXML seems to skip a tuplet indication (I don’t know if this is just in Finale, I don’t have Sibelius or other softwares for testing) …

Please ignore the music ! It’s just a draft :grinning_face_with_smiling_eyes:

xml VS etf - Score.pdf (801.7 KB)

#2

Dear Mauro,

It’s hard to tell starting from a pdf :slight_smile:

If you can send me the second measure of the alto part, say, as a voice, with the noteheads (if possible). It could be related to notehead error parsing.

(I don’t know if it is Finale’s parser or our export of notehead’s syntax which is faulty. I believe it is worth to take a look at it…

Best
K

#3

Dear Karim, here you can find the xml and the etf of the 1st violin. The rhythmical problem are in bar #11 and bar #24.

Cheers !
M.

Vno1bis.musicxml (236.7 KB)
Vno1.etf (137.2 KB)

#4

Ok,

I confirm it is not a Finale’s problem. I think it is om related (export) with either noteheads or text added issues, or both. Got to check this in the code and try to fix this.

However if possible, can you send me the voice with the extra changes so i can trey to figure it out?

Best
K

#5

Here it is. I tried using the bare sequence, without extras, and the problem persists …

vno1-karim.omp (241.5 KB)

#6

Thanx a lot.
this did help. It has nothing to do with the extras…
I can see now the problem. It is a bug (euuuuchhh!).
I am on it.
Will keep you posted.

Best
K

#7

Dear Mauro,

Voila a fix but to be tested before integration. So to be put in the init folder:
mxml_fix_271021.lisp (5.2 KB)

And if anyone has sibelius dorito, or others, please test with embedded tuplets and “false” embedded tuplets (ie binary groups in tuplet groups).

And if you can report back so i can integrate the fix in the code.
Or if still other problems appear, will be glad to have your feedback

Best
K

#8

thanks Karim, works great in Finale. I don’t have any means to test it with other softwares though …

All the best
M

#9

Hi Karim ! I just discovered some other bugs in the export of rhythms via MusXML. Here you can find enclosed a patch with 3 problematic cases. They all involve tuplets which end up being hidden (at least in Finale) and with the wrong denominator …

rtm-errors-musxml.omp (14.7 KB)

#10

Hmm…

Yes indeed. I am looking into it. This happens when you have a group not equivalent to the measures’s denominator. It’s little tricky, but i am on it.

Thanx Mauro for reporting this.

Best
K

#11

Dear Mauro,

here is the fix:
—

When you can tell me if this works for you so i can push it in the code.

You can ignore (remove the former one in this post).
Best
K

#12

Hi,

Here a complete fix (also for musescore):
fix-250822.lisp (5.8 KB)

Best
K

#13

thanks dear Karim, I’ll check it asap !

#14

Hi,

I am a Sibelius user, and a while ago, I researched nested tuplets in Sibelius and OM.

The musicxml developer did add feedback. Maybe this can help in something: Doubt about tuplets. · Issue #429 · w3c/musicxml · GitHub. Seems that there is an error with nested tuplets <time-modification>

And, using the XML code in this issue, fixing it, Sibelius did not read the nested tuplets correctly.

Then I did some tests and found this:

  1. Sibelius is unable to read nested tuplets from the musixml built by itself (rsrs).

  2. Sibelius can read the nested tuplet that the two levels start together, and any other tuplets seem not to work.

  3. Sibelius has a few aleatoric nested tuplets that work, and I could not find what works and what not!

In my opnion, the problem with nested tuplets (in Sibelius) is Sibelius, not OM.

#15

Dear Charles,

I don’t have Sibelius, so i cannot confirm your statement. However, what i do know:

  1. Musescore, doesn’t handle nested tuplets in musicxml even if it was exported from musescore itself. So it seems it is the same case with Sibelius.

  2. What i remember is that Sibelius DID in fact handle nested tuplets back in sometime days. I cannot tell you what version, but it seems that they have changed their musicxml parser’s behavior.

Did you try the fix patch above ?

BEst
K

#16

Dear Charles,

Just read the thread you were referring to above, and i have some remarks:

  1. Musicxml is not as it is supposed to be a univerals xml encoding for music. Apparently, each proprietary notation software (Finale, Sibelius, MuseScore, etc.) seems to have their own “decoding” principles for this format, which makes it really complicated for a developer to support.

  2. Moreover, Musicxml from version to version expands their encoding rules and makes also things very heavy to follow. (Just to let you know, that the first code I wrote for OM export was based on the musicxml format 1.0).

  3. The big issue i think personally that musicxml seems to have as a universal music notation encoding format is that it mixes musical hierarchical syntax with graphical display which some notation software require and some not. So either you adapt a minimum notational content that will satisfy all softwares, or you write for each of them a particular export code, which forgive me to say, is not satisfactory and time consuming.

Best
K

#17

Dear Charles,

The time-modification issue is as you say the multiple of all fractions of embeded tuplets. I will modify this in order that you may test it in sibelius. Finale, doesn’t complain about it as if ignoring it.

Will send you ASAP a fix.
Thanx for reporting.

Best
K

#18

Dear Charles,

Here is the fix. You can put it ALONG the previous patch:
fix090922.lisp (277 Bytes)

Tell me if this fixes the xml output.

Best
K

#19

Great thanks a lot! I will try it!