"Pan score automatically" in Continuous view does not take into account the "sticky" system header and jumps to far, so some music is obscured by the header

[scorezforstuff]

Note added by \@cbjeukendrup for clarity: this issue is about the automatic scrolling behaviour. Every time that the viewport is advanced because of the playback cursor getting almost out-of-view, the new viewport is placed in such way that the notes currently being played are placed immediately at the left edge of the viewport, and thus get obscured by the "sticky" system header. Instead, the notes being played should be at the right edge of that sticky system header, like MS3 did.

---

Describe the bug When viewing scores in the Continuous View Mode, the left hand side info that cannot be turned off cuts off the first bit of new score on the next page. This is behaving different from MuseScore 3 - in MuseScore 3 the score didn´t jump ahead as far and the left hand side didn´t block off new parts of the score. In MuseScore 4 now the score is jumping ahead fully and the left hand side blocks off the first new bit, essentially making it impossible to make scrolling score screencaptures in MuseScore 4 that were working in MuseScore 3 (this part is a shame as the automatic formating in MuseScore 4 is miles ahead of 3).

It´d be amazing if this could be fixed in a future update.

To Reproduce Open any score in Musescore 4, set to continuous view and then check that there is a bit of the score blocked when it jumps ahead. If you still have it installed check the same score in MuseScore 3. The left hand side will still block something, but the software will jump ahead further to ensure that you can read the score continuously without missing notes.

I added screenshots and screencaptures of this happening.

This is MuseScore 4

This is the same score in MuseScore 3

Screencapture in MuseScore 4 https://user-images.githubusercontent.com/124154918/216035468-568c7534-b3cf-491a-9be6-fc6f501afd35.mp4

Screencapture in MuseScore3 https://user-images.githubusercontent.com/124154918/216035819-c57f4c5c-2939-4a43-a628-2e08a4cb761b.mp4

[konstantinblaesi]

I have the same issue using the AppImage on Fedora 37 with wayland. I would like the page turning mechanism - at least in horizontal scroll mode - to be somewhat configurable, for example:

• when is the page turn triggered? Is it at the very end of the last bar of the current page or earlier?
• will the next page include a fractional amount of the last bars from the current page? I think including some will make following the score easier instead of making a page turn like a physical page turn

Details: OS: Fedora Linux 37 (Workstation Edition), Arch.: x86_64, MuseScore version (64-bit): 4.0.1-230121751, revision: github-musescore-musescore-9b70a8c

[scorezforstuff]

• will the next page include a fractional amount of the last bars from the current page? I think including some will make following the score easier instead of making a page turn like a physical page turn

This is how it was handled in MuseScore 3 and I think it will be necessary to include something like that again. In the long term it would also be amazing to be able to turn the left header off completely to not block anything, but for now being able to use MuseScore 4s superior layout in scrolling videos would be amazing

[jz6363]

Same here. Note was all visible in MU 3 as the page change is earlier, just that the playback is not as smooth, MU 4 playback is much smoother but notes blocked/missing in continuous view as the page change is too late.

Here's the difference: MU3 https://github.com/musescore/MuseScore/assets/111832274/e51fa732-07f2-4a3a-9b04-73730313b075

MU4 https://github.com/musescore/MuseScore/assets/111832274/e37eaf10-498f-4dfc-ac15-054f3433a9ad

[nCuky]

@konstantinblaesi said:

I would like the page turning mechanism - at least in horizontal scroll mode - to be somewhat configurable, for example:

• when is the page turn triggered? Is it at the very end of the last bar of the current page or earlier?
• will the next page include a fractional amount of the last bars from the current page? I think including some will make following the score easier instead of making a page turn like a physical page turn

I want to add my take: It would also be helpful if we could set that the screen changes right at the start of the bar that is cut from view, and not just when the last visible note is played. Currently, if the last visible bar is cut by the edge of screen, so that for example only half of it is displayed, the play head moves until the last note in the first half, then the screen changes to display the next note in the last half of that bar, and the playhead is placed on it. I would like it if the app would "know" that this last visible bar is not displayed in full, and then when the playhead gets to that bar, the screen will change right before the bar itself is played, and not during it. This way the whole bar would be displayed before the playhead actually starts playing it.

In addition, I strongly support @konstantinblaesi 's second suggestion, that the next page should include a fraction of the last visible bar.

[dcorson-ticino-com]

Note also that this is not only a problem during playback. The same mechanism happens during note entry. When entering a note at the right edge of the window in continuous horizontal mode the screen jumps too far to the left and depending on where exactly in the measure the insertion was one or more notes can not be seen. Note that this depends on the exact placement and relationship between the notes and the window, sometimes it is OK, often, not. I would suggest that at least the last note entered should always be visible at the left edge.

[cbjeukendrup]

Let's keep this discussion focused on the bug which it is about, namely that it doesn't take the "sticky" system header into account.

For any other requests, like making the scrolling behaviour configurable, please open a new feature request.

Thanks!