[MusicXML] Not all accidentals imported

If you check the MusicXML file with text editor, you'll see that the accidentals are probably exported OK since they are in the MusicXML text. They are not imported OK. Also, be aware that MusicXML supports only a subset of the accidental shapes found in MuseScore.

Cross referencing to another appearance of this issue: http://musescore.org/en/node/29066#comment-117756

Microtonal accidentals are attached to natural note and they are given the USER flag.
The bug in import is very similar to #23680: MusicXML import: Some accidentials not imported.

Proposed pull request:
https://github.com/musescore/MuseScore/pull/1162
this has to be tested.

IMPORTANT: the musicxml export and import should be checked against the accidental values of MusicXml 3.0, see here:
http://www.finalemusic.com/UserManuals/MusicXML/Content/ST-MusicXML-acc…
In particular, the export should be corrected for example for the arrow-up and -down accidentals,
i.e. at lines 2252-2270 of mscore\exportxml.cpp
https://github.com/musescore/MuseScore/blob/master/mscore/exportxml.cpp…

I tried to update these values, but got stuck since I know almost nothing about microtonal accidentals and the images of quarter-sharp and slash-quarter-sharp in the finalemusic page look identical to me (are they the correct pictures?)

Moreover, I think that in the import, at lines 3976 and 3998 of importxml.cpp the natural-sharp (-flat) should be mapped to sharp (flat) in absence of an actual natural+sharp (+flat) implementation [which I think would be only needed after a double-sharp (double-flat)].

I am working on the import/export of microtonal accidentals from/to MusicXml. I will add this work to the existing PR.

Would it be possible/feasible to extent this to playback of these microtonal accidentals?
The info which offset to use in libmscore/accidental.cpp#L39 ff

...Wow, there was some work needed, but import/export should give the expected results with PR:
https://github.com/musescore/MuseScore/pull/1173

Unfortunately, I had to partially rewrite the previous PR because of a bug in MusicXml export from a Sibelius 7.5 Demo.

@Jojo-Schmitz: For what concerns the playback, I'm sorry but I have very little idea about what to modify and also how to modify the pitch. If you look at the PR, you can see that I set the "alter" value in export/import only for 1/4 and 3/4 tone accidentals, since I used the 01d-Pitches-Microtones.xml file from the Unofficial MusicXML tests from LilyPond as a reference, but I don't know the correct value for the other accidentals. I see that the offset in the accList are the same for different accidental types: is it a shortcoming or is it correct?
(for example, "sharp arrow down" and "sharp-slash" and "natural arrow up" all have +50)

BTW, not sure if you saw this discussion or are aware of the change I made to how microtonal accidentals are handled during note entry, but see:

http://musescore.org/en/node/26296

If there's something you don't like about how I did things, now would be a good time speak up (or fix it yourself :-)

@ABL: I'm not sure whether is a 100% correct for these microtonal accidental Tuning offsets, as there seem to be various conventions: I took these from the defaults of miwarre's microtonal plugin .

@Jojo-Schmitz: I don't know either :-) It's probably better to put the playback issue in a separate issue report for future development. I don't think I have the "courage" to dig into it (at least at the moment...)
@Jojo-Schmitz and @Marc Sabatella: I regard my PR (which I think needs a little cleaning before being merged) as a first working/almost-working implementation just to patch the strange behavior of microtonal accidentals. And here is the link with the correct observation by Marc.
I read the discussion and the problem is that the 1.3 and the current implementation of microtonal accidentals is obviously still not treating them as "actual" accidentals. From this point onward, all we can try to do to "patch" this behavior will be wrong somewhere.
I don't think that a proper implementation will be possible in MuseScore 2.0 [I really don't want it to be further delayed... :-) ]
I prefer a correct behavior for scores created from scratch; referring to the import of the G#,G3/4b,G# score from 1.3 I would make the accidental on the third G visible, whatever it is decided to be (I would vote for a G#, so that no possibly complicated guessing algorithm should be written for the import).
Consider another thing: if you then add the complication of transposing instruments everthing becomes a mess.
Attached are two xml I exported with MuseScore version patched with my proposed PR (transposing.xml and transposing2.xml): if you import it in Sibelius only one behaves properly. I don't recall all the passages I did to write it, but a series of switches from/to concert pitch were involved.
Even without going into the details of MusicXml import/export, consider a single 1/4 flat F written for the horn. If you trigger concert pitch, what note should it become? Should it be a 3/4 flat B (1/4 flat + flat B)?
And what about a 3/4 flat F? Should it become a 1/4 flat A ( flat B +3/4 flat = double flat B + 1/4 flat ?)? In principle, depending on the tuning I think there should be difference between a double flat B and an A.
In conclusion: I would not suggest a rework for MuseScore 2.0, but just a "patched" behavior which works in limited cases (e.g. non-transposing instruments), so that there is a working work-around for people using this feature. Then we can do a proper implementation for MuseScore 2.1 or 3.0.

P.S: If you try to import the attached files (transposing.xml and transposing2.xml) in Sibelius, it converts the 1/4 flat F to 3/4 flat B and the 3/4 flat F to 1/4 flat A when switching to non-transposing mode, but only for the file with the "alter" tags.
Moreover, if you export from Sibelius a note with a 3/4 flat (not through Dolet), when imported in MuseScore with my PR it is treated as a note with a flat and a 3/4 flat. See file accid_sibelius.xml: in the debugger you see that the 3/4 flat C has pitch 71 and tpc 7, while the 1/4 flat C has pitch 72 and tpc 14, and the 3/4 sharp C has pitch 73 and tpc 21; if you create these notes from scratch they have all pitch 72 and tpc 14. Visually they are indistinguishable. How should the import behave?

After the PR and the further (great) work by Leon Vinken on key signatures, this bug can be closed.
An actual implementation of microtonal accidentals as "true" accidentals deserves its own report as a feature request.
Some of the accidentals in the initial report can no more be processed since they were removed from MuseScore (because they are not part of SMUFL).
I am closing this report as fixed. Please re-open if needed.

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