[MU4] Fix incorrect choice of accidentals on notes with same midi pitches on capx file import.

[Jojo-Schmitz]

Port of #6032, plus adjusting 2 unit tests (both for test 4), which actually prove the fix right.

Resolves: https://musescore.org/en/node/304625 issue b), issue a) seems fixed in MusicXML import since long, but still exists in Capella import

[Jojo-Schmitz]

No idea why test7 fails:

--- /home/runner/work/MuseScore/MuseScore/src/importexport/capella/tests/data/test7.cap-ref.mscx	2023-12-02 40:54.643392665 +0000
+++ test7.mscx	2023-12-02 14:00:53.023549224 +0000
@@ -417,8 +417,11 @@
           <Chord>
             <durationType>eighth</durationType>
             <Note>
+              <Accidental>
+                <subtype>accidentalFlat</subtype>
+                </Accidental>
               <pitch>61</pitch>
-              <tpc>21</tpc>
+              <tpc>9</tpc>
               </Note>
             </Chord>
           </voice>
   <diff -u /home/runner/work/MuseScore/MuseScore/src/importexport/capella/tests/data/test7.cap-ref.mscx test7.mscx failed, code: 1 
../src/importexport/capella/tests/capella_tests.cpp:64: Failure

That Capella file doesn't show any accidentals in Capella Reader 8:

But does in MuseScore, with this PR:

Would it be OK to adjust the test? Or is there s bug in Score::spell(), esp. with that key signature, C#-Major/Ab-minor?

[cbjeukendrup]

It might be a bug with Score::spell() indeed... or maybe it's not a bug and Score::spell is being rather "too smart"?

[Jojo-Schmitz]

So the question is whether there really is a bug inScore::spell()(or rather in one of the methods it calls), or whether to just outsmart it by adjusting the test 7 (both test 4 apparently did the same thing prior to this PR ;-))

Fixing a bug in Score::spell() would be out of scope for this PR, so let's outsmart it.

[Jojo-Schmitz]

@cbjeukendrup any news here?

[cbjeukendrup]

I'm quite uncertain about this. There are two questions:

• Isn't calling spell a bit overkill here? It seems a simple per-note contextless algorithm might suffice. But I don't have any experience with Capella at all, so I can't really tell.
• About that bug in that test: is this really a bug in spell, or is it because spell is trying to be context-aware while that is not desired in this case?

[Jojo-Schmitz]

Hmm, to be honest I have no idea.

[cbjeukendrup]

I'm afraid we'll really have to look for a different solution. Here's a slightly modified version of the test file:
test01 kopie.capx.zip

(that's what it looks like in Capella Reader 8.)
Note the two different enharmonic spellings of the D#/Eb. But both master and your PR import both notes as the same note; master goes for D# and your PR goes for Eb.
Conclusion: this PR is shifting the problem, not solving it, so to speak :)

[Jojo-Schmitz]

Should we then close this?

[Jojo-Schmitz]

Hmm, 4.2.1 and latest master does this with that Capella file:

My PR makes it this:

so my PR gets 3 right, 1 wrong, master gets 2 right and 2 wrong, to me that is an improvement ;-)

Probably this is sort of the same issue as that with test7.cap, 'fixed' in that 2nd commit, a Db/C# (and an octave lower), see measure 9 in the images above