Screen jumps to top when scrolling past bottom of score during playback
--Steps to Recreate:
- Open any score; with many instruments to better view bug; Recommended: Marching Band
- Make the first page consist of only 1 system
- Add a vertical frame above the first system - by Add>>Frame>>Insert Vertical/Text Frame OR Add>>Text>>Title/Subtitle/Composer/Lyricist/PartName
- Zoom in to where some staves are off the screen
- Start Playback
- Scroll down to bottom of System
- Scroll down more
--Expected result:
Screen scrolls past bottom of staff to where there is blank "paper" on the screen or the background is visible.
--Actual Result:
Screen resets scroll to the top of System.
(Windows 10)
Not sure if this could be considered a "Bug", but it does not happen without the Vertical Frame or Text Frame and it can be recreated in previous versions of Muscescore
Comments
I've experienced this. Perhaps your explanation will allow those who can do something about it to understand.
What version are you using? While I remember this sort of thing happening in older versions, I cannot reproduce iit in a current build of MuseScore 3 Beta. If you can, could you record a screenshot video so we can see the steps more exactly.
In reply to What version are you using? … by Marc Sabatella
My recorder does not allow for playback, so I made a picture of page 4 of the attached score. Set up the score so it approximates this view and you will see the score display jump to the top when playback starts. The most important part of the setup is to not be able to see the piano and trombone II on the screen at the same time when you start play. While these measures are playing, try to scroll down and the entire bottom staff of the piano will never be visible. Slowing down the tempo will give you more time to see the effect of this.
I have chose not to display the entire screen in the forum. The picture is of course the .png file and the score is the .mscz file.
This will not happen on every page. It happens on page 1, which does not follow my theory, but otherwise it seems if there is less than a certain amount of space between the last staff and either the next system on the same page or the bottom of the page, this jump occurs. For example, it doesn't happen on pages 2 & 3. Larger symphonic pieces may show this better, but I believe this shows the issue sufficiently and I had it handy.
In reply to My recorder does not allow… by mike320
Your picture doesn't quite match the score - order of instruments differs, and I don't have two systems on page 4. So I can't quite reproduce your scenario exactly. As it is, I can guess the issue might have to do with having a portion of two different systems visible at once?
In reply to Your picture doesn't quite… by Marc Sabatella
Try this file. guess I forgot to save it after I setup the instruments.
Saul A3 - S1 - 2 Sinfonia.mscz
In reply to Try this file. guess I… by mike320
Yes, I see now. The algorithm for positioning is kind of complicated because there are so many different cases to consider. Normally if the whole system fits, we're good just positioning it however, but if the system doesn't fit we try to keep the same vertical position on the page, because we don't actually now which staff or staves you might care to keep in view as the playback progresses. So this only works for pages with a single system, otherwise of course keeping the same vertical position would totally miss the next system. And trying to track specific staves would be problematic because the staves and their spacing can change from system to system. No doubt we could at least try, but in order to do so, we would need some way of tracking more information about which staves you were looking at, and right now we just don't have that information available at the point in the code where we are trying to figure this out.
Anyhow, that's a description of the problem if you want to submit it as an issue: the canvas pans to top of the system if it doesn't fit on screen and there is more than one system on the page.
In reply to Yes, I see now. The… by Marc Sabatella
I would suggest that the solution is to allow for 1 to 2 staves worth of space below the bottom staff of the current systems being played to be visible. It would not bother me at all to see a little of the system below the last staff so I can see the last staff. After you respond to this, I'll enter a bug report.
In reply to I would suggest that the… by mike320
But then you won't be able to see the top staff - again, we don't at this point know you weren't currently looking at that. All we know is the system doesn't fit, and you were X inches down at the time.
In reply to But then you won't be able… by Marc Sabatella
If you use some common sense and don't change the top of the view you'll be able to scroll up and down and see the part of the score you want to see. There's no way to see all of the staves if they don't fit on the screen. That's something I can live with, because there is no fixing that. When I have a page full of 35+ staves of symphonic music, there's no way I can read the notes and text if I make the entire page fit on a screen. If there are two systems on the page it's also impossible to see the last displayed instrument. I want to be able to see the contrabass (or last instrument displayed) part along with the rest of the strings while the song plays, which is impossible right now.
In reply to If you use some common sense… by mike320
What I am saying is, if the whole system doesn't fit, we have no good way of knowing which staves you want to see. if you say you want to see the bottom, that's fine, but that may mean it will then scroll down to the bottom always, even if you were viewing the top. I can't imagine you'd want that. And maybe what's not obvious is, we can't just keep the same vertical position unless there is only one system per page, because keeping the same vertical position will mean we will never go to the second system. We don't have a clear way to say, "keep the same position relative to the system the cursor is currently on".
Ideally, I think, we'd somehow figure out the top of the system was in view and if so, make sure it stays in view, and do the same if the bottom is in view. Not entirely sure how feasible that is, but it might be. There probably wouldn't be any good way to keep the same staves in view if neither the top nor bottom is in view though.
In reply to What I am saying is, if the… by Marc Sabatella
Your obviously not thinking. I use the mouse wheel to scroll up and down, it doesn't do this itself. When there are too many staves on the page you have to use the mouse wheel to see the parts of the score you can't already see. The problem is that it's impossible to see the last staff because the display jumps to the top as soon as you get the bottom line of the last staff on the screen. It's impossible to see any notes below the staff and almost impossible to stop the scrolling so you can see any of the staff.
PLEASE someone who isn't convinced we don't know what we're talking about join this conversation!!!
In reply to Your obviously not thinking… by mike320
Can we PLEASE stop making personal judgements like this? I am thinking., as are you; we are simply miscommunicating. I have no doubt I am not doing a great job of explaining what is happening in the code in terms easily understandable to a non-programmer but I am trying my best.
I do believe I understand perfectly well what you want to see happen - you want the view to stay vertically focused on the point you are scrolling to. Of course you do, anyone would want that, it makes perfect sense. I am trying to explain the technical issues why this is easier said than done, so that you can help me make come up with a reasonable alternative that will actually be implementable.
Again, the issue is that at the point in the code where we need to decide how to position the view, the information we would need in order to "keep the current staves in view" is just not available. So we have to find ways of finding good behaviors based on the information we do have available.
In reply to What version are you using? … by Marc Sabatella
Sorry. I should have mentioned: This is in the Musescore 3 Beta.
To be precise: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.0.0.4516, revision: 59a11cd
The website won't let me attach my recording to this comment - might be too big a video (about 80MB) - but I can give a link to a Google Drive file if that's okay.