Beat is skipping due to too many subdivisions

• Jul 10, 2018 - 10:47
Reported version
S4 - Minor

I recently encountered this issue where the playback skips a beat in Musescore 2.1. I believe this is due to too many subdivisions being encountered, and the engine not being able to properly handle it. In the attached PNG file, on beat 4 of the first measure, the beat skips to the next measure. In beat 4, I have a note offset by a 16th note duration, an 8th note followed by two 32nd notes and a 16th note, and a division of 7 all occurring within the same beat. I also have a 70% 16th note swing notation marked to begin on beat 4.

Attachment Size
beatskip.PNG 61.14 KB


Can you share the score here? Dies it still happen in 2.3.1 (2.1 is outdated since quite a while)? Does it also happen in a development build from the master branch?

In reply to by crasherX8

Hi guys tried the file here and cannot replicate the problem on my Mac because all my instances to crash as soon as I try to open the file....

Versions 2.3.1 release and latest development build for 2.3.1 and current master (3) and a very slow low resource machine...

On about the 2nd / third try it opens up and has some signs in the notation of corruption in the file (from observations with my experiences in using unstable versions of the app) ... when I can get the app to not crash on reading the file it all plays as notated however I will add the notation has some missing notes where I would expect there to be a note... The completed piece would be a good testing piece :)

In reply to by Ron Southworth

I'm not sure why it would be crashing for you, the file is working fine on my end. Sorry about that!

But yes, it misses out on some notes, which I believe is likely due to the amount of subdivision counting the engine has to 32nds, swung 16ths, straight 16ths (using quadruplets), glissandos, and septuplets. It's no surprise that it's struggling to deal with that amount of information.

Status (old) active needs info
Status active needs info

Measure 26 doesn't look like the one in the png? And I don't see it missing a beat there.

The latest development build crashes on loading that sample score. That needs to get fixed first, before looking into whether or not it also loses a beat.

Fatal: StaffText unknown (216), data (...\libmscore\element.cpp:1040, virtual bool Ms::Element::setProperty(Ms::Pid, const QVariant&))
So unrelated to a possibly missing beat. Shortly before though it gives this:
Debug: Tuplet 0x35e43b78 sanitized (...\libmscore\tuplet.cpp:1090, void Ms::Tuplet::sanitizeTuplet())
Which might hint at a problem with the score

In reply to by crasherX8

Thanks for the advice.
Yes I've done the export and import of Music XML to clean up some of my scores before

it is a worthwhile tip for people...

No Probs on it crashing
File Systems Between Different OS when they write/read don't necessarily create exactly the same file size or have different "padding" at times...

Sorry I cannot be more help. I like your interpretation of the original (Hal David Burt Bacharach - {Carpenters et al cover version}) I have notated the ASPUB version of the song. It use to have a problem in playback on my slow machine, however since the big effort on the synth interfacing it plays as I would expect it to without missing a note. That is what peaked my initial interest in the topic...

Severity S5 - Suggestion S4 - Minor
Status (old) needs info active
Status needs info active
Tags View Changes

I can reproduce. It becomes obvious if I turn on the metronome.
Something is wrong with score itself... If I remove content of the 24th measure, I still hear the incorrect beats processing and jump from the last beat of the measure to the first beat of the following measure. If I then undo the removing, beat processing becomes correct.

Whatever was causing the problem with the skipped beat seems to have been fixed in the master branch.

I have attached version of the score that loads in master without causing it to crash. There was a Staff Text object (coincidentally, in measure 24) whose style was set to "Text Line". This was causing ScoreElement::initSubStyle() to set properties for the Staff Text object that are not present in TextBase, which was triggering the qFatal() in Element::setProperty().

Attachment Size
Close_to_You.mscx 491.4 KB
Status (old) active fixed
Status active fixed

As 2.3 won't receive any fixes anymore, and master doesn't have the issue, we can consider this issue fixed.

For me, it is noticeably different when comparing master with 2.3.1. I admit it may sound a bit odd, but I think it is just the way the music is written. I find it helps to focus on the melody line.

That said, I'm glad you're not taking my word for it. I uploaded the modified score so that testing could continue.

In reply to by mattmcclinch

I'm still having the issue on the attachment.

What exactly was the fix? How can I fix it myself? You mentioned it was a style "Text Line" in measure 24 - I remember having some text that was set to invisible in a previous version, which would change the swing temporarily for those 4 sixteenths that are marked as straight, but I got around that by using quadruplets. Are you saying there's a text line there that isn't visible to the editor that's causing the problem?

Status (old) active fixed
Status active fixed
Reported version 2.3 3.0

The nightly build (master branch) seems to be playing the measure back correctly. It must be something with 2.3.1, fortunately we know it will be fixed now. Thanks for all the help guys!