Saving during playback causes it to skip to a random note and hang, moves playback cursor elsewhere
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Always
Status
needs info
Regression
No
Workaround
No
Project
I notice it a lot because MS2 gave me the habit of saving during playback so I didn't waste time. But it skips around oddly - sometimes the playback cursor(if you hit spacebar twice, where it starts again after you end the hang) is only a beat or so ahead of where it should be, sometimes it's reset to the beginning of the score.
Comments
I think the majority of the playback issues are this bug - if there is an autosave during the playback, this happens.
I can't reproduce, but I gather others can, and it does sound worth investigating further.
There's at least one confirmed duplicate, and I strongly suspect most of the playback issues reported are this.
I have experienced similar problems, but in my case they occur spontaneously during playback. There was a suggestion that it might be caused by autosave, but my experiments seem to indicate that this cannot be the sole cause. See "Playback halts temporarily (MS3 beta 2bxxxxx)" under the links above for the discussion.
Jeroen noted that there was definitely a problem during autosave. I got an interesting one where the playback cursor skipped ahead a few bars a breath or two after I manually saved.
In reply to I can't reproduce, but I… by Marc Sabatella
Marc It is more noticeable with a large file size arrangement I suggest download something with multiple instruments and more than 100 measures.
As of the daily OS: macOS 01e2f04 it has improved the issue quite a lot. Almost about as good as you can expect it to be, note auto save also impacts on playing.
FWIW, it wouldn't occur to me to expect smooth playback while saving, that seems. What if we just disabled it, or queued it to not save until playback ends?
Useful post in the forum:
jeroen2442 • Dec 11, 2018 - 06:43 new
In reply to Does auto save only work in… by jeroen2442
I have some final information that might help.
I did the same run: start MS3, load score, changed note, playback while watching autosave folder.
I ran it twice. First time, after a while autosave occurred, no delay noted in playback. Second time, when autosave kicked in, replay halted temporarily. The runs were identical, except I did not restart the program in between.
One difference was that in the first run the size of the autosave file was 8 kb, the second time it was 24 kb. I have no explanation for that and it seems odd to me since the scores saved were identical and changes made were minimal.
I have repeated the experiment one more time, with identical result.
I now firmly conclude that:
when delay occurs, it is triggered by autosave
autosave alone does not trigger delay, some other unknown condition must also be present
there may be an issue with the size of the autosave file.
OS: macOS 10.14, Arch.: x86_64, MuseScore version (64-bit): 3.0.0.19686, revision: 2b25396
In 2.3.2, saving would cause your display to hang. You couldn't do anything but wait for the save to finish, which was very annoying on large scores. Except... you could play them back, check for errors. The display wouldn't respond until saving finished, but the music would keep going, and everything was correct once saving was finished.
I would really prefer that this would be the case again - I've worked on scores where every save took thirty seconds. And if saves are being oddly inflated, that's definitely a bug, one that will get more problematic as scores get larger.
This bug report appears multiple times in the feedback form.
Is there any example of score for which the issue can be reproduced? Or does this happen always regardless of the score being saved?
EDIT: well, I see, it should be just large enough for saving process to be relatively long.
I do not think my score was overly large. 73 measures, 4 staves and a grand staff. Autosave size between 8 and 24 KB.
When autosaving, playback halted for several seconds on a machine that is certainly not sluggish. Is it conceivable that all that time was spent saving such a small file?
What I see:
* the same behaviour is in MuseScore 2. Regarding the https://musescore.org/en/node/279050#comment-877227, it is not the case for my system in MuseScore 2.3.2. It hangs and stops playback as well.
* saving score during playback is not a typical scenario
* cursor jumps not randomly but to the exact place which would play if playback wouldn't stop/hang. So, cursor jumps to the correct position
What I think. We can disable the ability to save the score during playback. We can stop playback when saving the score.
The most beautiful solution would be to save scores in parallel (in separate thread) with other operations. It will require more work and testing, and UI tweaks. So, I would postpone any decision on this issue.
In reply to What I see: * the same… by Anatoly-os
1) If you choose to disable saving during playback to solve the problem, you also should disable autosave, since that can trigger exactly the same behaviour. See "Playback halts temporarily (MS3 beta 2bxxxxx)" on this forum.
2) I would strongly support a decision to autosave in a separate thread. (Or alternatively / additionally: what about playing back in a separate thread? I have noted other issues with playback, perhaps not related to (auto)saving, that were too transient to report but were still annoying, and might be solved this way.)
I do realize the effort needed, and I am saying this with all due respect and admiration for all the fine work done. But I think a program with the maturity that MuseScore aims for, simply should have it.
In reply to 1) If you choose to disable… by user2442
Absolutely, you are right. Playback in a separate thread is also a good thing to do.
The basic issue is understood well, then, so I'm removing the "needs info" status.
Given the frequency with which this comes up, I would strongly recommend we simply disable the autosave during playback for initial release. I think if someone hits the save button themselves, they should be entitled to have the score saved but shouldn't be surprised if their system can't keep up.
I have done some more research on this problem and found something new about it. First, from the user perspective, this problem (or at least the problem which I am able to reproduce):
1) Depends on playback position in a score (that's why I had some problems in reproducing it).
If playback goes somewhere in the beginning of a score then the problem is unlikely to appear. The further the playback position goes from score start, the more likely it is to spot the problem and the harder will be consequences (sound glitches and/or playback stopping).
2) Does not occur if you work with
.mscxfile.From the technical point of view, the reason is that playback (already being in a separate thread from score saving) uses the score's
RepeatListto map ticks to real time on playback (and, possibly, do some other playback-related mappings), andRepeatListuses score's tempo map for that calculation. Tempomap is currently being cleared on score layout. That way, if file saving causes score layout (which is the case for thumbnail generation for.msczfile) then the score's tempomap will contain no data for the part of the score that was not laid out yet. That causesRepeatListto return incorrect values which makes the sequencer produce bad playback. If playback position is in the beginning of a score then it is likely that tempomap can be rebuilt for the relevant part of the score till the time when its notes playback should go, it takes much more time for more distant parts of score. That explains the observations I described above.An unexpected consequence of this is that this pull request which is intended to fix another issue will make this problem almost improbable, and its consequences almost unobservable. It does not fix the reason itself (rewriting tempomap while it is being used by playback) so some problems are still possible (but maybe there will not be any) but it should be much less likely to happen.
Of course, a proper solution for this problem is still desirable but maybe it can be done with a slightly less priority since the problem seem to be largely mitigated by the mentioned pull request — at least if the problem which I describe is the problem that is discussed here.
Thank you, @Dmitrio95. Let's see if this helps.
Not helping. The playback either skips measures or hold notes indefinably.
I don't think the fix is implemented yet. See this for an explanation of the fields you changed. "Won't fix," for example, means that we will not even try to fix the problem, since it is not our problem or it is already fixed in the next major release and no minor releases will be released before the major release.
The PR mentioned above was merged into master a month ago, so in theory this should be fixed. If someone has some specific score where it is not, we would need that score to be attached so we can investigate.