Beat is skipping due to too many subdivisions
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 |
Comments
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 Can you share the score here… by Jojo-Schmitz
I don't have the development build but it does occur in 2.3.1.
I've attached the score below, the bug is in beat 4, measure 24.
In reply to I don't have the development… 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 I don't have the development… by crasherX8
export the file as musicxml
then open exported musicxml file in musescore.
while the file is loading, you can see a list of corruptions and messages in the warning window(s) that pops up.
In reply to Hi guys tried the file here… 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 do...in 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.
Measure 26 doesn't look like the one in the png? And I don't see it missing a beat there.
Ah, I see, you're talking about measure 24
I still don't see it skipping 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.
Error:
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 I'm not sure why it would be… 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...
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().
As 2.3 won't receive any fixes anymore, and master doesn't have the issue, we can consider this issue fixed.
I can reproduce in master. Let me try to attach the mp3.
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 I have attached version of… 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?
Select the "straight 16ths" text in measure 24 and use the Inspector to change the style back to the default. You will then have to reposition the text.
This simply allows the score to be loaded in MuseScore 3.0 so it can be tested there. You can download a nightly build of MuseScore 3.0 from https://musescore.org/en/download#Development-builds.
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!
Still @Anatoly-os could reproduce