System being edited stays fixed on current page until editing an earlier system
Reported version
3.2
Priority
P1 - High
Type
Functional
Frequency
Many
Severity
S3 - Major
Reproducibility
Randomly
Status
active
Regression
No
Workaround
Yes
Project
Oftenly when you use the "Page Break" resource, parts of measure disappear from the score.
It is a very simple bug to reproduce. Just use Page break and you will notice that parts of the score disappear
Comments
In order to investigate we would need you to attach the particular score you are having trouble with any give precise steps to reproduce the problem. I am unable to reproduce any problem with page breaks. Prior to 3.2 there were other occasions where measure could temporarily disappear - not from using page breaks, but from using spacers or other changes that forced a system to another page - but that should be fixed now.
In reply to In order to investigate we… by Marc Sabatella
Now that you mentioned, I just realized that it is a bug not always related to the Page Break. Sometimes some measures disappear when the system rearranges itself. To experience what I am reporting, try this on this file:
1) enter on the Flute part.
2) do a page break at the end of the first section, for example.
3) give play. You will see that some measures are simply gone (the blue cursor will start pointing at some random spot on the score).
Maybe it's some OS specific problem? I am using the App version of Musescore 3 on Ubuntu 19.04.
In reply to Now that you mentioned, I… by Yuri Stremel
2) Alternatively, ou can just edit the text of page 5's tempo. Add something like Allegro. It will force some changes on the system that also vanish some measures
This sounds like #290154: Display on playback gets confused when text frame added to start. I abandoned (maybe ignored is a better word) this issue when a related issue to disappearing measures was fixed. I haven't noticed my issue recently, but I've not been manually changing layouts before saving either. If there were an easy way to look at issues by their creation date it would be easy to see the issue Marc S fixed related to this.
I wasn't able to reproduce the problem you describe with page breaks - are you using the latest version (currently 3.2.1)? As I mentioned, there were some bugs that were fixed recently that maybe could have caused some similar problems.
However, I can reproduce a problem where in some cases, a system can be pushed right off the bottom of a page rather than onto the next page where it belongs. And it seems likely I caused this with one of my fixes for 3.1 or 3.2, probably relating to #290210: Bad layout of pages >1 after edit.
Here are steps to reproduce the problem I see (which is probably related to the second problem you describe, except I can't reproduce it in that case):
1) select the "rall. molto" on the last system of the first page of the flute part of our score
2) press Ctrl+Up to move the text up
3) keep pressing
Result: last system gets pushed right off the page.
I was able to reproduce this scratch for a minute, then I wasn't, so more investigation (by me) needed.
What I have experienced when I saw similar results is this:
Open a score with multiple systems on pages.
Alter the page layout so a system should move to the next page (I found this initially by entering a frame and putting a page break on it).
Press play without saving the score (saving fixes the problem).
What is being displayed will not be the same as what's being played.
I would say that problems involving the playback cursor not doing a good job of tracking exactly what is being played are most likely unrelated, certainly a much more minor problem than what was originally described here and what my steps above reproduce, which is some measures just disappearing entirely, layout of the score of the score completely wrong, etc. So I'd rather keep this critical issue focused on those use cases - music disappearing entirely, or at least being pushed into margins where it shouldn't be. Separate issue reports can be opened for playback-tracking issues. I know those exist, and have investigated several that proved too complex to fix, especially without a consensus on exactly how to best handle certain cases. So again, let's move that discussion elsewhere, so when I figure this more serious issue out, we can close it.
BTW, I may have misstated the steps above in a way that may be a clue. It turns out I can reproduce the problem every time - on 3.2 as well as 3.0.5 - if I attach the staff text to the second measure of the last system, but not if I attach it to the first. So it might not be a regression per se, not against 3.0.5 anyhow. Also, it fixes itself on the next relayout.
Somewhat shockingly to me, I can reproduce this going all the way back to the alpha. Here's a simplified case with only two systems on a short page:
If you then do something to trigger a full layout (incuding wait for autosave to kick in), it fixes itself as mentioned. But if you then move the staff text back down, the system does not move back to the previous page. You have to go back to the previous page and do an edit before it's fixed:
My take on what is happening is that, when we do a layout of the modified range of a score, it seems we start with the page containing the current system - we don't bother to check the previous page to see if it can take the system. Furthermore, we assume the current system will definitely fit on the current page, and only start checking to see if there room when we get to the next system.
I think the fix for both aspects of this is probably to start the process using the previous system. We don't necessarily need to lay it out again, but we need to start the collectPage() process there. It looks we already do some things to back up a little bit before starting, but apparently not enough. With luck it's a very simple fix, or it could be one of those that requires more work.
Anyhow, as serious as this looks a first glance, the fact that it's gone unnoticed for the better part of a year (and that it eventually fixes itself) makes it a little hard to call it critical.
Note to self, this is still an issue, and I do think my proposed fix of starting layout a system earlier will do the trick.