XML Export wishlist

I’m part of a team of engravers doing a big digitization project for myhymnary.org. I have to submit my final product as a musicxml file so it can be made into a dynamic score using verovio. Thus, musicxml export is critical to me. With the recent improvements to xml export in 5.1 it is so close, but not there yet. I still have to export into MuseScore to take advantage of their more complete xml export capabilities. This is my wishlist, somewhat in order of priority.

Bar numbers for incomplete bars should be excluded from the bar count. In hymnals, bars are often split to match the meter of the text. For example, a hymn with an 8.6 meter would split after 8 syllables, then 6 regardless of where in the music that split happens. The only way to currently do this is to change the meters in the bars where the splits are. This results in 2 bars. Each bar with different bar numbers in the xml output. The first of these two bars should not have a barline at its end. The latter of the two bars should be excluded from the bar count. Other notation programs mark the latter bar as “X1, X2, etc” in the xml output.

An invisible barline is absolutely needed for splitting the measures as described above. I don’t know of any workaround that will export.

(Along these lines, it would be nice if, in Engrave mode using Shift-S to split in the middle of a bar, it would automatically create the two separate bars, the first with an invisible barline, the 2nd not counted in the bar count. This would really speed things up for me).

Pickup bars at the beginning are currentely exported as bar 1. They are already marked as bar zero in the system track so why aren’t they exported as bar zero? In looking at the xml output from other notation software, they mark such bars as bar zero.

Italics in lyrics need to be exported.

Stemless notes aren’t exported.

The elision symbol “‿” in lyrics is not exported. It looks like the xml exported puts the two words in separate tags and ignores the elision character all together.

Dashed ties and slurs are not exported.

Cued notes are exported as regular sized notes.

Lines and lines with text (eg. solid line with inward pointing hooks) are not exported. I’m still testing whether voltas (1/2nd ending text) is exported properly or if it is an issue on our end.

I need a way to assign a fermata to just one note in only one staff of a multi-instrument setup. For example, in a soprano and bass (singers) piece I am often asked to replicate the original material that has a fermata only above the top note in the treble clef and no fermata at all in the bass clef. (I know, not standard notation, but when a publisher that’s paying for the project you’re working on says it has to be done that way, it would be nice to have a way to do that. I’m surprised how many hymns require this).

If there are two text items at the same spot in a measure, they get exported as a single text item on two separate lines.

Rehearsal marks are not exported.

Cued sized (75%) staffs are exported at regular size.

An option to not display lyric extensions, in general and in xml export would be nice. There are ways to workaround this problem on a word by word basis but that adds to the time spent on a project that wouldn’t have to be spent if there was a global option to not display them. Very few hymnals that I’ve run across include lyric extensions.

I’m not sure if it is an xml export issue or a problem on our end but I have an issue with 8th note beaming. In one piece, from ms. 1 through 4 all of the 8th notes are not beamed. It is only in ms. 5 that the notes are beamed (and the only spot in the xml that the tag appears) but yet all the 8ths are beamed throughout the music. If an export issue I’d bump this up to the top three things I’d like to see implemented.

2 Likes

Thanks for taking the time to provide your detailed feedback on what is still missing from MusicXML for your purposes. We’ll do our best to tackle a number of these as soon as it’s practical for us to do so.

Regarding rehearsal marks, they are meant to be exported already, but when we changed them to use a paragraph style rather than a font style a while back, we neglected to update the MusicXML export side of things, so they are currently missing, but I’ve fixed that, so that will be all right in the next update.

With regards to beaming, Dorico is definitely exporting beaming for notes in general. If you have any further information about the project where you’re finding no beaming information is exported, we’d be glad to take a look to see what’s going on there.

1 Like

A possible bug in xml export in 5.1.1 and other comments on the 5.1.1 xml export additions. Thank you for them.

Every file I export that I try to load into MuseScore gives me this error:
“Fatal error: line 121 column 69 Element direction contains unknown attribute system.” Loading into Sibelius didn’t give me the error. Loading into Finale said that the attribute System is not allowed in the element direction. I got that same error on several lines in Finale.
(in this example, the first line showed is line 121)

<direction placement="above" directive="yes" system="only-top">
        <direction-type>
          <metronome>
            <beat-unit>quarter</beat-unit>
            <per-minute>88</per-minute>
          </metronome>
        </direction-type>
        <staff>1</staff>
      </direction>  

Slurs from/to different voices don’t display when trying to import into MuseScore (although the file has < slur type=“start” number=“1” orientation=“under” line-type=“dashed” dash-length=“5” space-length=“3.125”/> and the corresponding “stop” tag in it. Interestingly the “stop” type comes before the “start” type. I don’t know enough about musicxml to know if that’s correct or not. A slur from/to the same voice does work fine and with dashes and has the start tag before the end tag.

Items I’ll keep on the wish-list:

Export of italicized lyrics (currently exported as regular text)

Export of Lines (which I believe xml refers to as brackets). I was trying to export the “solid line with inward-pointing hooks” line and nothing was exported.

When splitting measures in half, an invisible bar line is sometimes needed. Xml has the “none” tag for bar-type, why can’t Dorico have an invisible bar line?

Beaming works fine. It was a problem on our end. If the encoding software type wasn’t MuseScore it would ignore the specified beaming.

Thanks.

Thanks for the feedback. Could you attach a Dorico project that when exported produces the error/warnings concerning the system attribute? Likewise, a project that exhibits the issue you’re experiencing with slurs between voices would also be helpful.

RS2016-159 Gospel.dorico (855.9 KB)
I put a few comments in the project. I think this one shows everything I discovered (so far) and a possible issue with chord symbols (at least when it gets imported into verovio). Thanks.

Thanks for the file. I’m unable to reproduce the issue you report with the system attribute with this project, either. I’m importing into editor.verovio.org, Finale 27, and MuseScore 4.2, and none of them is showing any kind of error.

I can see the issue you describe with the chord symbols showing naturals in Verovio, and we should be able to address that in future.

I believe the slur is being exported correctly – it seems to appear as expected in Verovio and in Finale, though it doesn’t appear at all in MuseScore.

As you know, we’ve not attempted to handle text formatting for lyrics or brackets in this update, but those things remain on our backlog and we will address them in future.

I’m using version 3 of MuseScore (I like it better than 4) and get the error. Finale 26 gives me multiple errors as I described. Sibelius 2023.11 doesn’t report an error. I only rely on MuseScore for importing xml. I wasn’t aware of the verovio editor. I was relying on myhymnary and whatever processing they apparently do to my uploads as representative of what verovio does.
I did run across one other thing
I’ve discovered that verovio doesn’t like this:
< direction directive=“yes” system=“only-top”>
but prefers this
< direction placement=“above”> (with or without the above tags)
This was for a segno symbol and D.S. repeat text that it kept putting beneath the staff instead of above. I suspect it might affect other items too.
The metronome marking in another piece I was doing includes < direction … placement=“above” …> and verovio puts it on top.

When uploading the file to the verovio editor, the slur is present, but it is not dashed as in the original dorico project.

MusicXML is a moving feast. It is not yet a universal standard. So different programs have their own import and export capabilities. And each is developing at a different pace.

A case in point…

Clearly MuseScore4 has enhanced MusicXML import capabilities over MuseScore3.

MuseScore 3 and Finale 26 don’t support MusicXML 4.0, and the system attribute is a MusicXML 4.0 feature. You’ll need to use MuseScore 4 and Finale 27 to take full advantage of these new Dorico MusicXML export features. Alternatively you can just ignore the messages.

I’m delighted to see the great improvements to MusicXML export in these recent updates!

4 Likes

A big “YES please!” to annotating italics in lyrics in MusicXML. I need to compare 10s of thousands of words of lyrics from Dorico to other sources, and the lack of italics makes that, well … you can guess. Also, that must one of the easiest fixes, no? A single attribute of a single tag? Perhaps I’m deluded :wink:

Every time somebody posts this on an internet forum, a developer dies. (If not actually, then at least on the inside.)

We definitely plan to include more formatting information about lyrics in MusicXML export in future. It’s not as simple as it might appear because in our testing thus far, no importing application handles this correctly, with the possible exception of Finale. The approach we believe we need to take is to define items in the <defaults> element for different types of lyrics (regular ones, translations, choruses, translated choruses) and then providing the right named style to each lyric as appropriate when it’s exported. So far as we know, however, no application actually respects this on import – apart perhaps from Finale.

1 Like

Didn’t mean to kill anyone. ;-). For people like me, who develop their own tools for this sort of thing, just the ability to hang any old attribute on an XML element would be grand. I’m not sure how you would implement such a thing, but just to put the idea out there, some kind of table/setting that would allow us (meaning the Dorico community) to essentially map some Dorico properties to XML would make Dorico uniquely powerful. Because for me, I don’t need the rest of the world to correctly interpret “italics” (for example), I just need some mark in Dorico’s output that represents my own score.