musescore / MuseScore

MuseScore is an open source and free music notation software. For support, contribution, bug reports, visit MuseScore.org. Fork and make pull requests!
https://musescore.org
Other
12.26k stars 2.65k forks source link

MusicXML import shows red notes when <midi-program> is set to guitar #21742

Open guiv42 opened 8 months ago

guiv42 commented 8 months ago

Issue type

Engraving bug (incorrect score rendering)

Bug description

When importing a MusicXML file with following properties, some notes appear in red unexpectedly:

<midi-instrument id="P1-I1">
    <midi-channel>1</midi-channel>
    <midi-program>26</midi-program>
</midi-instrument>

midi program 26 is a steel string guitar. See example file attached below, with one single A3 note: it appears red, while it fits correctly in guitar's amplitude. After deleting node (and child nodes), note appears correctly in black

Steps to reproduce

  1. Open attached MusicXML file test.zip

Screenshots/Screen recordings

Screenshot_20240228_223330

MuseScore Version

OS: openSUSE Tumbleweed, Arch.: x86_64, MuseScore version (64-bit): 4.2.1-, revision: github-musescore-musescore-

Regression

I don't know

Operating system

Linux OpenSUSE tumbleweed (rolling release)

Additional context

No response

oktophonie commented 8 months ago

An import matter, not engraving. The note is red because it's considered out of range; the problem is that the instrument is being identified as a cavaquinho: image

Jojo-Schmitz commented 8 months ago

It is a Mu3 regression (3.6.2 imports it as Acoustic Guitar)

Cavaquinho happens to be the 1st entry in (Mu4's) instruments.xml using <midi-program>26</midi-program> (resp. <program value="25"/> <!--Acoustic Guitar (steel)-->, note the off by one between MIDI-program and program-value), Acoustic Guitar being the 2nd. Seems the matching ignores the (octave) transpositioning?

In Mu3's instruments.xml Cavaquinho too turns up before Acoustic guitar, but the 1st entry for this MIDI/program value is the Bouzouki, still Acoustic guitar is taken on import, so the order doesn't seem to be the (only?) reason.

But just fixing the order should fix this issue here. I don't see any reason why Cavaquinho should be before Acoustic Guitar, but Bouzouki after?

I've just verfied that changing the order indeed helps here.

shoogle commented 8 months ago

I don't see any reason why Cavaquinho should be before Acoustic Guitar

It's because the Cavaquinho plays in a higher range than the Acoustic Guitar. Instruments are ordered by minimum playable pitch, which is how you would expect to see them in the score. We can't change this ordering to fix a MusicXML import problem.

but Bouzouki after?

This is because the Cavaquinho and Acoustic Guitar are both in the guitars family, but the Bouzouki is in the bouzoukis family. Instruments are sorted by family first, then by minimum playable pitch. (Family orders are defined here.)


How to fix the issue at hand

During MusicXML import, instruments are identified here. First it searches MuseScore's instrument database for a matching instrument by MusicXML instrument ID. If it doesn't find a matching ID then searches by name. If it doesn't find a matching name then it searches by MIDI program.

The search functions are defined here. In particular, the name search only returns a result if the name in the MusicXML exactly matches a trackName, longName, or shortName of one of our instruments. This code should probably be updated to allow a fuzzy text match, and return the instrument that has the highest fuzzy match strength, or nothing if the fuzzy match strength is below a certain threshold value (which would be determined through experimentation).

At the moment, only exact matches are considered. The instruments are searched in order, hence if it gets to the MIDI program search, the first instrument with a matching MIDI program is returned. Ideally we would fix the name search so that it never gets to the MIDI search. However, we could also maintain a list of MIDI program numbers and the instruments that they most commonly represent, so that MIDI program 25 (26 in the MusicXML) would always return an acoustic guitar rather than searching our instrument database for the first instrument with this number.

Jojo-Schmitz commented 8 months ago

Ah, I see. Here the XML has <instrument-name>Steel String Acoustic Guitar</instrument-name>, but there's no such track-, long- or shortName in instruments.xml, so it falls back to the MIDI program number.

The diff between Mu3 and Mu4 seems to be in the 'cleverness' of searchTemplateForInstrNameList(), Mu3's is much simpler.

shoogle commented 8 months ago

No doubt MU4's search function was made cleverer to avoid some other problem with instrument detection, so the solution would be to make it even clever rather than reverting to MU3's function.

Jojo-Schmitz commented 8 months ago

I didn't want to imply otherwise. Also my claim that changing the order would fix it was not meant to be the real fix, sorry, more a troubleshooting hint

shoogle commented 8 months ago

That's fine. I wasn't trying to criticise you, but we do need to say what the right solution is for the sake of anyone reading who might want to fix it.

Jojo-Schmitz commented 8 months ago

Sure

pacebes commented 1 week ago

Hi I am trying to deal with this issue looking into combinedTemplateSearchfunction.

I had some initial problems because I didn't notice my language setting was "Spanish". Every long and short name in instruments.xml is translated to the local language so, importing an XML exported in another language could also generate problems because text would not match. I don't know if it could be better to export and import them always in English (part-name, instrument-name, part-abbreviation ...).

A potential proposal could be:

I think this could be a way to avoid collateral damage.

pacebes commented 1 week ago

I have made some tests with Levenshtein algorithm (Wikipedia Version) and the "distance" with "Steel String Acoustic Guitar" would be:

Therefore in this specific case using long Names it would have worked because "Acoustic Guitar" is the closest. I have asked a friend about this options and he suggested to me using embeddings.

I would appreciate any suggestion. I could create a pull request with the Levenshtein algorithm that would work in this specific case. Please, give me any feedback

Jojo-Schmitz commented 1 week ago

I'd say: go ahead, that Levenshtein algorithm is a fuzzy search like @shoogle suggested

pacebes commented 1 week ago

I don't know if I should have been assigned to this issue before creating the pull request. Please, give me any feedback in the pull request.