tablature bug importing from musicxml

• Jun 2, 2020 - 00:54

It seems that the tablature bug (resetting fingerings) rears it's ugly head. Here is the file after importing it in finale, soundslice and (at the bottom) musescore.

It seems tablature needs some work.

Attachment Size
tablaturebug.png 315.25 KB
ex5.musicxml 43.73 KB


and even worse is that if I export an MP3 from the imported musicxml, musescore is generating a D natural on the first note (G) so it ends up being the diad {G D}. Hmmm...I can't upload an mp3 but if anyone's interested, I can email

In reply to by Jack A. Zucker

I can't reproduce this either. The mp3 I generated sounds as expected, first note is a plain G. What version of MuseScore, what OS? Can you upload the mp3 to Dropbox or Google Drive or the like?

Hmm, are you maybe using a custom soundfont? The unison G could be triggering audio artifacts due to phase effects, and this could produce harmonics. Does it happen if you mute one of the staves?

It’s not clear what you are saying the bug is. Can you give precise steps to reproduce the problem? Including the score file itself if that’s part of the steps.

In reply to by Marc Sabatella

look at the attached png file. The first two have correct tablature (finale and soundslice), the 3rd one which is musescore has completely wrong tablature. The first two are as exported, the musescore looks like it issued itself a reset-tablature fingerings update and it's all wrong.

There seem to be some serious deficiencies in the tablature handling in musescore. Just curious, do you guys have regression tests written for this? Some of these things should be caught by automated testing. If not, you should consider going through a release cycle and writing unit and int tests.

In reply to by Jack A. Zucker

Ah, I was confused by the word "fingerings", I thought you literally meant the missing fingering p i m a symbols, which as explained is normal given the default settings. Seems like you actually are referring to the string / fret assignments?

Anyhow, I tried importing the file you attached, but it doesn't look like your image at all. Here is what I see: for the first measure, for example:


Looks like the others to me, not like your picture. What version of MuseScore were you using to import? I tried with both the current 3.4.2 and a development build of what will become 3.5, both gave this same result. or maybe you changed your import settings? I'm using all defaults.

Anyhow, it would indeed be a serious deficiency in MsuicXML import of tablature if this didn't work, but for me it is. Aside from the minor gltich you reported where copy-paste loses fingerings when used in the unusual way you had accidentally discovered, are you seeing other problems? Overall I think you'll find the tablature feature quite robust and full-featured, with lots of special editing commands and style settings to cover everything from Renaissance lute tablature to several different styles of modern rock. Not that there isn't room for improvement - there is, with every feature of every program, of course. But again, overall I think you'll find it pretty solid.

And yes, we do have a pretty extensive automated regression test suite that is run on each and every proposed change to the code, and nothing is merged without passing them 100%. Generally if a bug is fixed, we add a new regression to cover that case. So if you should choose to file a bug report on the copy/paste glitch, chances are pretty good that would also be added to the regression suite (apparently no one ever tried copyu/pasting this way before).

In reply to by Marc Sabatella

well, i don't know what to say. i'm using 3.4.2 on windows 10 64 bit. And it's 100% repeatable. Not just on this file, but on every musicxml file I import, it displays open strings in the tablature whereas the exported file contains no open strings.

Is there some global configuration option for the tablature that I'm missing? The tablature is completely wrong on EVERY xml file I import. It uses the lowest fret possible and as many open strings as possible. It really makes the program unusable tbh. If I can't get past this bug, it's a dealbreaker for me.

Attachment Size
tablaturebug2.jpg 17.79 KB

In reply to by Jack A. Zucker

Yes, this is what MuseScore does when entering notation by pasting into a tab staff or when using linked staves and entering notation into the standard staff. But import is import, totally different story it should read the string and fret info and present them literally, and does and always has for me. That's what makes me wonder if you are leaving out some step in your description, like doing a copy/paste from standard to tab after import. That's the only thing I can of that would cause this.

In reply to by Jack A. Zucker

Can you attach some other MusicXML files that are problematic for you? Maybe some clue will appear. You sure you are literally doing nothing else but opening the file, eg from File / Open? No other editing operations after that?

Again, it works fine for me, and does in every version I tried going back several years.

No special config options for tab import I can think of. Unless, I suppose, you've been messing about with custom instruments.xml files or custom default MSS style files ion Edit / Preferences. Even then I don't think there would be any way to mess up a MusicXML import that way. The only MusicXML import settings are also in that same dialog, but they won't affect this.

I can confirm the bug on 3.4.2 Win10 x64
Opening the ex5.musicxml from the OP shows 3 3 3 0 3 3 0 1 for me. Performed a rest to factory settings to be sure.

The good news is that 3.5 alpha shows the correct string/fret combination on my system. So it looks like that was a bug that is now fixed :)
#287131: MusicXML import ignores string/fret

In reply to by jeetee

I must apologize, I have so many versions installed on various systems I must have lost track of which was which when testing last night. My screenshot that I thought was done with 3.4.2 must have actually been with 3.5 alpha. So I had tried the alpha, a current build, 3.0, and 2.3.2, and all worked as expected, but I too can now confirm that 3.4.2 gets it wrong.

However, I double-checked and still cannot reproduce any issue with MP3 export using 3.4.2. First note is a G for me,

I tried to trace where the bug fix might have been made to be sure this isn't a fluke, and it's a bit hard to follow the history in this file since it was moved recently, but I suspect the fix came here:

Do you still have an unanswered question? Please log in first to post your question.