[MusicXML] Export of nonsense chords

Checked:
- .mscz file opens correctly in 1.1 (i.e. it does show a chord called "ChordName")
- .mscz file opens correctly in current 0.9.6 branch (i.e. it does show a chord called "ChordName")
- .mscz file opens correctly in current trunk (i.e. it does show a chord called "ChordName")

All versions fail to save the chord to MusicXML, but no error message is shown.

All show the chord properties as root=C extension=other. This is an invalid chord that cannot be written in MusicXML.

The MusicXML exporter in 1.1 ignores invalid chords. The 0.9.6 branch and the trunk (i.e. 1.2 and 2.0 to be) implement a fall-back: invalid chords are exported as plain text (in a MusicXML words element), thus preventing information loss.

I intend to accept the 1.2 and 2.0 behaviour as "good enough" and leave it unchanged.

Both the current (as of end of last year) 0.9.6 branch and the trunk export invalid chords as text. It is only the 1.1 version that ignores invalid chords on MusicXML export. The attached xml file is tagged (in the file) as generated by "MuseScore 1.1", but the svn revision is not mentioned.The mscz file states programVersion 1.1and programRevision 4611, which matches the released version of MuseScore 1.1. This is still exactly what I would expect.

Note that the current 0.9.6 is identified in the MusicXML file as "MuseScore 1.2" and the trunk as "MuseScore 2.0.0".

I have the same problem in 1.2. Here's some additional info:

I added chords to a song and saved in standard mscz format. When I reloaded the song the chords were not displayed. To see if the chords were there I saved as xml and there they were tagged as "harmony". When I reloaded the xml file into musescore they appeared again!

While taking the xml roundtrip does make the chords appear again it is quite cumbersome in the long run.

I attached both my files, hopefully the bug will show itself in your end.

I'm running your 1.2 windows build 5470 on a Windows7 / 64 bit.

In the above example, the chord description file is set to "chords.xml". That is not a valid value - this file is used for other purposes. It contains no chord rendering instructions, and that is why the chords do not appear. Change to any valid chord description file (eg, stdchords.xml) and the chords reappear.

Regarding the original report, the XML file posted contains no Harmony objects, so there is nothing to display. So, no bug in 2.0.

The MSCZ file contains an unrecognized chord - recorded in the file as plain text - so it cannot be exported to MusicXML without re-parsing it. So again, no bug in 2.0.

Now, starting with 7c7ca30, if you try entering "ChordName" as a chord name into a score, it actually will recognize this as a chord of sorts, since the first letter "C" happens to be a valid root name. So it will parse as a chord whose root is "C" and whose extension is "hordName". Thus it will render normally, and even transpose - as "DhordName" if you transpose up a major second, for example. You might question whether this is desirable, but it pretty much needs to do this in order to support the semi-random extensions people might reasonably try to create that don't fit the "rules" (like, say, "E7Hendrix").

MusicXML export is another matter, though. Currently, the MusicXML export behavior will be to export nonsense chords that happen to start with A-G it as a plain major chord. So it will export as C major. There is no way to export "hordName" meaningfully, since it is inherently meaningless. However, it would be possible to attach "hordName" to the exported Harmony object as a "text" attribute to the "kind" tag (perhaps giving the latter a value of "other" instead of "major"), and on import, MuseScore itself would actually read this and give you back what you started with - a nonsense chord that at least renders and transposes normally.

Before I actually look into making this happen, though, I wonder to what extent this is really the right thing to do. And also, whether I should go ahead and export even chords that don't begin with A-G in a similar way. So that "N.C" and other deliberate non-chords one might enter are exported in a way that might render better when imported into another program. Most programs, it seems, ignore the "text" attribute, so I don't know that this approach will actually work. I plan to investigate this myself, but welcome feedback.

I've renamed and reclassified this issue to reflect the actual situation.

Regarding N.C. I would export it as kind "none" and not "other". Finale 2012 builtin export seems to defaut to C major any unrecognized chordnames (such as NC)... and so it looses the info in a round trip via MusicXML. For "Chordname", it will ask if you want to add "hordname" in the chord library or delete it to get a C major chord in the interface (and then in MusicXML). If you add "hordname" in the library, it will export "Chordname" as a direction with words "Chordnames" and not an harmony element.

Yeah, I realized after poking around a little that "none" was better suited for "N.C." However, there is a practical issue with using either "none" or "other" for this purpose. I wouldn't want there to be a root tag in the harmony element for this, but if I create a harmony element with no root tag, MuseScore complains on import that it is not a valid XML file. This complaint comes from the schema validator, and my read of the standard suggests that indeed, root is not optional. Well, it can be replaced by a "function" tag, and that can apparently be empty. But what's funny is the changelog for Finale's Dolet plugn explicity says better support for N.C. was added years ago, and also support for *import* of kind none with text. And it sure seems like this is something that should have a clearly-defined right way to handle. But if so, it's still a mystery.

Well, for now at least I've made it so "ChordName" exports as kind other, text hordName, so it will export and import more like any other chord. N.C. works well enough within MuseScore - it's only the issue of how to best export/import it that I wonder about.

We could ask on the MusicXML mailing list. I don't use the Dolet but the builtin MusicXML export. Did you test the dolet?

I didn't test anything on the export side, because all I have easy access to right now is Finale Notepad, which doesn't support creating symbol symbols at all. I did try import, but nothing I tried stuffing into a MusicXML file resulted in Notepad displaying "N.C.". Also, I do have scores lying around from when I did use Finale, but I can't be sure how I entered things. The "N.C."'s in my old files I found export as plain text, but these would have been created before 2008 which is when Finale supposedly starting supporting N.C. better.

So, I like the idea of going to the mailing list. I just subscribed and will ask when that gets approved. There's a few other questions I had along the way I wouldn't mind getting "official" word on. Actually, one such question I should ask here first: anyone know why we set default-y to "100" when exporting chords as plain text (eg, for "N.C.")? It's really way too high. I'm guessing we do it because the first example in the official tutorial shows it that way, but they are trying to create room for a fretboard diagram.

Only lvinken could answer the question about "100". But I guess it's an hardcoded default like any other. Using a value computed from the chordname style would probably be better.

Don't know :-(, I cannot remember. I'm afraid export of layout information is incomplete and/or possibly incorrect anyway.

At best it is a hardcoded default that, sometime in the (near ?) future, must be replaced by a properly calculated value.

I'm not so sure it's possible to calculate something that would really be meaningful. After all, there is no default-y value exported for "good" chords, so they will be imported using whatever the importing program's own defaults are. I suppose I could come up with a value and put it on both "good" chords and ones exported as plain text.. I'm still unclear on how the positing stuff is supposed to work.

Or - I tried just removing that default-y setting from the plain text versions, so it imports at whatever the default for direction / words is. As it happens, this looks a whole lot better using default settings in MuseScore, Sibelius, and Finale than default-y=100 does.

But if it's possible / acceptable to somehow export these "chords" as kind none with appropriate text, I'd prefer that, as then they'd automatically be positioned consistently with other chords also render with the same fonts, etc. So I'm still planning to ask on the MusicXML list.

I tried Finale PrintMusic 2011 (I still have it) and set a few chord symbols to "N.C." and a few other valid ones, and exported the XML. Upon loading the XML, all the "N.C." imported into Finale as "C". So "N.C." was recognized as a valid chord symbol, as it explained in the online help, but the export changed it. Did I miss something?

Maybe not. That's what lasconic says he sees too. But changelog on the MakeMusic site says as of 2008, "N.C. and alt chord symbols are exported and imported more accurately." Exporting "N.C." as "C" hardly seems accurate to me. Maybe it's a question of Dolet plugin versus native MusicXML, but I don't know.

I read that too, but the changelog didn't say it was in Finale. Many of the entries specifically said they were in Finale, but many were not specific. Also, N.C. is a recognized chordname so I can't see why it isn't exported. Does Finale also allow exporting via the Dolet plugin? I could download and test that...

I had thought the Dolet plugin was what Finale always used. Certainly, I never went out of my way to download anything b that name, but that's how the MusicXML stuff was labelled in the older versions of Finale I used. Smething else Zj can ask about nce I'm n the list...

Finale can import and export MusicXML natively, the piece of software responsible of this is the "Dolet light". But there is also a plugin for Finale "the Dolet plugin" (not light), which was developped independently by Recordare, the company of Michael Good, father of MusicXML, before it was bought by MakeMusic. The changelog you are refering to is the one of the dolet and not the dolet light. So for best result, we should probably use the last version of the dolet. The dolet is now free against your email address, (but use to cost 199$). http://www.musicxml.com/dolet-plugin/

Update:

The change to export "Chordname" as kind of "other", root "C", text "hordname" is in. So otherwise unintelligible chords that at least start with A-G will export in a way other programs have a chance of rendering as expected.

Still not thrilled with how arbitrary text like "N.C." gets handled, and I never got any confirmation that my application to join the MusicXML mailing list succeeded, so I still can't ask there yet.

FYI, the consensus on the MusicXML list is to export N.C. as a kind of "none" with a text attribute of "N.C.", and a root-step of "C" with a text attribute of "". MuseScore does not currently deal with text attributes on root-step elements, but I've gone ahead and implemented this. The implementation also cleans up the handling of "N.C." internally and in MSCZ files, not just for MusicXML. The MusicXML representation is still kludgy and not well-supported by other programs, but I feel this is the best that can be done, and an improvement in all respects.

Fixed in 55ed042ec0

Automatically closed -- issue fixed for 2 weeks with no activity.