Open guiv42 opened 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:
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.
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.)
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.
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.
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.
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
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.
Sure
Hi
I am trying to deal with this issue looking into combinedTemplateSearch
function.
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.
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
I'd say: go ahead, that Levenshtein algorithm is a fuzzy search like @shoogle suggested
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.
Issue type
Engraving bug (incorrect score rendering)
Bug description
When importing a MusicXML file with following properties, some notes appear in red unexpectedly:
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
Screenshots/Screen recordings
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