Scroll during playback issues.
I looked for this and can't find it. We had a discussion back in version 2. During playback, you can scroll up and down to see various staves in a system when the system is larger than the screen display. When you playback and all of the staves do not fit on the screen, it is impossible to see the last staff unless it is the middle of 3 systems being played. When you scroll down to see the last staff, the display jumps back up and the last staff disappears below what can be seen. Also, if you scroll to see the bottom of 2 or more systems, when it gets to the next page, it does not always pan that page so the system is visible. This is true of version 3.1-beta. A good sample score is Psalm 119 III Gimel and Daleth.mscz. Set up the zoom so you can see the Piccolo through the Bassoon II and press play. Use your scroll wheel to try to look at the Bass staff during playback and observe that at best you can see about the top half of the staff unless there are multiple systems.
I see both of these issues in this score.
Comments
Yes, this is the one I specifically remember as well. I spent quite a while investigating what was going on, and agreed there is an issue, but one that is complicated by the way our data structures and algorithms are set up. What I recall was trying to come up with a reasonable behavior - meaning, a good compromise between what might be desirable the most often and what is actually implementable - but we never quite found a solution. So, that could be a good place to resume here. And then when some sort of consensus is reached, we can file an issue and see about implementing it.
The complications stem from the fact that from one note to the next (each time we move the cursor), we don't have a record of which staves we were just displaying. All we know if the vertical position of threported case e view on the page. You might think, just keep the same vertical position, but we also don't have a way to track this as you move from one system to the next, and a vertical position that makes sense for one system won't for the next, except in the case of only one system per page. So we handle that differently.
It's all a fairly complicated mess of special cases designed to fix other reported cases of the score not tracking as expected, so the trick will be figuring out to handle this without breaking the others. Luckily, there are ways of finding out which issues were fixed by which of the special cases, so as we go through and add new cases or tweak existing ones, we can make sure we don't break something else. But it's a rather laborious and somewhat trial-and-error process. So the better we can clearly define the expected behaviors, the better the chances of success.
In reply to Yes, this is the one I… by Marc Sabatella
The expectations are quite simple.
Problem 1 is that you cannot scroll down enough to see the bottom of the last staff in the system. I think the way to fix it would be to permit the user to scroll down to where the middle of the staff below that would be if it existed. This would ensure that in 99.99% of the cases you would be able to see all of the notes on the last staff and probably all of the lyrics below it. The .01% of the cases would be when there are no ottavas used on a piano and the lowest notes are annotated. There may then be too many ledger lines to see the bottom, but I'm not even sure that would be a problem and I've never seen that many ledger lines written on a score. I'm not a pianist though. The other limitation might be if there are several verses the user may not be able to see the last verse(s). Currently, what I see is that when you scroll down to see the bottom line of the last staff, the view moves as though you scrolled up one click.
Problem 2 is that when the user has scrolled to the bottom of a long system and the next system is shorter, there are times when no staves are shown until the user scrolls up. In this case the expectation would be that the bottom staff would be visible, preferably near the bottom of the screen or if it's too short with the top of the system at the top of the view.
In reply to The expectations are quite… by mike320
The expectations might but simple, but as I said, the implementation is another story. Let me try to be more clear:
The function responsible for this has no idea about the past - it doesn't know where you were before you started scrolling, it doesn't know what was happening when the cursor was in the previous measure, etc. It gets called every time the cursor moves, and it really only has four pieces of information to go work from currently:
1) what measure am I trying to show?
2) what region within what page is currently in view?
3) am I in continuous or page view?
4) am I in play or normal mode?
Based on this, it tries to figure out whether it needs to reposition the view at all, and if so, how. So it does a lot of checks for things like, "based on 1 & 2, is the measure I want to show already fully in view?" and "is the measure I want to show so close to the right border that it makes sense to move the view now", etc.
So the trick, again, is figuring out the best compromise between what is actually feasible given what we have to work with, and what would be desired.
What could possibly be interesting is to derive one piece of information about the past we don't actually have but can try to guess. If we could figure out while in play mode which was the previous measure we were trying to display, then use that plus 2) above to make a guess about which staves of the system the user might want to see, in the cases where the new measure is not currently in view. Kind of thinking aloud here, partially for my benefit as I continue to think this through, also to maybe give you an idea of the types of things that are implementable as we work toward some sort of solution.
In reply to The expectations might but… by Marc Sabatella
Maybe... A manual scrolling disconnecting the automatic scrolling... I'm not sure.
In reply to The expectations might but… by Marc Sabatella
The function responsible for this has no idea about the past I think it could look at the current display and see there is nothing being shown except maybe a few lines on the bottome staff being displayed. This staff should be at the bottom of the screen or the stop staff should be at the top of the screen with the rest of the stave below that, no matter how many staves that is.
In reply to Yes, this is the one I… by Marc Sabatella
Marc, I don't know if there's been any progress on this issue, but I'm using v3.4.2 and still encountering issues with this.
I'd like to suggest a possible solution to this that's possibly a little left-field. That's the ability to select one or more parts as "display focus". Possibly by groups of staves as well (e.g. those bracketed together).
I write a lot of orchestral music, but have zoom usually at 100% or higher because I'm vision impaired. What I'd like to be able to do is have, say, the strings as "display focus" during playback. That way, I can hear the other parts as normal, but visually the strings staves are kept in focus - and if I scroll away, the next render brings them back.
If I want to change the focus, I can always pause playback, change the focus, and resume.
This gets around the issue of not knowing what was previously displayed, because that information in this solution is supplied by the user as a "global" setting of some sort.
Best regards,
-J
In reply to Marc, I don't know if there… by Jason Wandel
That's not a bad idea, although I'm not sure what the user interface should be for how you'd specify this. Something to think about for sure. But - why not simply use continuous view? The problem doesn't exist there are seems a better choice for this situation anyhow.