Buggy Tempo Playback in MS 4
I just recently upgraded to Musescore 4 and I'm running into an issue with playback. Whenever I hit play, the score plays back at a tempo which is far slower than what is written. This issue is present in files from Musescore 3.6.2 being played with Musescore 4.0.0 as well as files created with Musescore 4.0.0.
I'm unsure of how to fix this aside from brute forcing things and just setting my tempo markings to ~2-3 times what they're supposed to be to get proper playback.
Comments
.
Mine is doing this too. Any progress?
In reply to Mine is doing this too. Any… by Beth Marmorstein
What OS? have you tried the things here: https://musescore.org/en/node/339915
In reply to What OS? have you tried the… by bobjp
MacBook Pro running Ventura 13.1. 16GB Memory. Processor: 2.3 GHz Dual-Core Intel Core i5.
The tips at that link must be for Windows because it doesn't exactly correspond to what's on my mac, but I've tried to do as much as I can. The audio Output is set to Internal Speakers. I don't have an Advanced Properties area for that that I can find.
I tried turning down the master volume and keeping the mixer open. Same behavior.
In reply to What OS? have you tried the… by bobjp
In addition to starting with the wrong playback tempo, mine also does this thing where it changes tempos spontaneously. It'll be clicking along (metronome on) at 60bpm, then all of sudden it goes to 120bpm for a beat or two, then back to 60bpm. When it does this, it is audibly faster/slower AND the metronome marking in the play panel changes. I feel like these may be related issues? I'm adding the score I've been working on, which was created in MS4. I've tried opening a couple of older scores that I created in MS3, and so far those seem to be fine.
In reply to What OS? have you tried the… by bobjp
I exported the problem score to .MXL and opened it in MS3. It plays perfectly. I guess I'm sticking with MS3 for a while longer. :-/
In reply to What OS? have you tried the… by bobjp
Update: My temp issues seem to be due to the fermatas. If I take out all the fermatas, it plays correctly.
I don't think the fermatas work correctly at all. Each fermata seems to change the playback tempo to 1/2. The problem is that if there are multiple parts with the fermata falling on different duration notes, the tempo change is applied at the start of the note and messes up the tempo/rhythm of the other parts. A lot of fermatas in close succession can have a recursive effect and the tempo goes crazy.
I'm attaching a simple test case. The fermatas in the second measure are meant to lengthen the last beat of the measure. But because the note in the baseline is a whole note, it apparently gets applied to the first beat of the measure and messes up the rhythm of the upper line, which ought to be steady quarter notes until the last beat.
In reply to Update: My temp issues seem… by Beth Marmorstein
For the purpose of playback, you don't need the fermata over the base line at all. If you need it for real players, set its time stretch in properties to 100%. Default is 200% or twice the note value. I think this is covered in the manual.
In reply to For the purpose of playback,… by bobjp
Okay, thanks for that. That is a workable solution for now, but I'd still rather see it fixed to play properly.
In reply to Okay, thanks for that. That… by Beth Marmorstein
That's the way notation software works. There is nothing to fix.
In reply to That's the way notation… by bobjp
That's not how it works in MS 3.6.2.
In reply to That's not how it works in… by Beth Marmorstein
Indeed, but that doesn't make it wrong
In reply to Indeed, but that doesn't… by Jojo-Schmitz
This is going to result in WRONG playback for a huge number of scores - scores that played perfectly in the previous version. This scenario (fermatas on different note values in different parts) is a super common one, it's not like it's some rare thing. If this was a deliberate change on the part of Musescore developers, I think it's a really terrible decision. I HOPE it's just a bug.
In reply to This is going to result in… by Beth Marmorstein
Not neccessarily, if the import keeps the stretch at 100%