Change automatic scrolling in continuous mode.

• Apr 11, 2018 - 19:42

871c8ce

At the moment, when entering note via keyboard in continuous mode, when I get to the end of the display to the right, the screen automatically jumps to the next page.

A great idea.

However I think it jumps too far.

Rather than redraw the complete next screen as it does now, it should keep the bar just worked on in the display. It should jump one bar less so that one can confirm the accuracy of what has just been entered.

Regards,

Comments

• Apr 11, 2018 - 21:33

+1 here.
Actually maybe even 2 measures - I find it disorienting when the context is lost by this kind of automatic jump.
Ideally, two things:
1. It should also be possible to disable this jumping so that the user can be in sole control of the paper movement. User configurable so that those who like the auto-scroll don't lose that feature - it seems a lot of people do like that.
2. In continuous mode, when the user manually scrolls the paper horizontally (whether by click-drag or by swipe) the paper should move only horizontally, not vertically. It's very hard to prevent the mouse from slipping slightly vertically when trying to move horizontally and it would be a big help if MuseScore would enforce a single-direction movement. Another way to look at would be to disable diagonal paper movement.

Reply

• Apr 11, 2018 - 23:23

  1. I would prefer auto scroll to be disabled over having to readjust the view every time MuseScore decides to make a wild jump that makes no sense. I would prefer the jump to always keep the last note entered and current cursor position in view every time it scrolls in continuous view.

  2. If you hold shift while moving the mouse wheel you will not get a diagonal scroll. Dragging is a bad idea because it's far too easy to grab an element in stead of paper and accidentally move it.

Reply

• Apr 12, 2018 - 00:01

I put it the way I did because there are unmetered scores where each measure takes up an entire line. The display algorithm needs to first look to see if it can display the last edited and next edited measure (so if your editing beat 3 of measure 4 both measures 3 & 4 will be displayed if possible). If this is not possible, then display the last note entered/edited (like adding a note to the chord or a tenuto mark) plus a little extra space before and then as much of the next measure as possible containing the next beat. Finally, the algorithm should only scroll if necessary to ensure the previous criteria are met. This will take into account that some people have different zoom levels. I keep my zoom somewhere between 150 & 200, others keep it at the default 100 while some with very bad eyes might make the zoom larger than I keep mine.

The end result would be that scrolling would only happen when you enter a note or rest that causes the next displayed note or rest to not be totally displayed on the screen since the cursor is highlighting that note or rest. At this point the screen would be redrawn as described above.

Reply

• Apr 12, 2018 - 01:09

Thinking about it I'm realizing that modern mouse gestures are what, for some users, make the auto-positioning more of an encumbrance than a benefit. For example, if you're using the the 2-finger swipe to move the material around you end up doing it more or less unconsciously in amongst the other gestures. So the page is always exactly where you want it because you've put it there yourself without even thinking about it. I'm guessing that's the reason why it's annoying when the app decides to move stuff of its own accord. Hence the need for an option to disable it.

Reply

• Apr 12, 2018 - 01:56

Yes, I was trying to illustrate with the example I gave there. It used to be quite onerous to move the "paper" around - for example you might have to mouse over to the scrollbar at the side of the window, move the paper, then mouse back to the work area - things like that. Therefore auto-positioning was helpful because it avoided having to do that. But today we have more sophisticated mouse gestures that allow us (among other things) to move the paper around with a two-finger swipe, without moving the mouse away from the work area. So the auto-positioning is not only unnecessary but actually can be obtrusive. That was my general point anyhow.

Reply

• Apr 13, 2018 - 17:01

FWIW, we definitely would like to figure out the optimum repositioning, but it's tricky. Consider, after entering a note, "most" of the time your intent is to enter another note after it, but sometimes it is to add a note to the previous chord, or otherwise edit the note you just entered. Often it's a good idea to have the full measure you are working on in view, but after enteri
ng the last note of a measure, we can't be sure if you are still working on the previous measure and want to keep that in view or if you'd rather keep the next measure in view. And if either measure is wide, it may be difficult to keep both in view. And in that particular case - what to do after last note of measure - it is even trickier in page view because of course the previous and next measure might not be adjacent, so it's practically hopeless - no matter which we decide, it's wrong half the time.

So these are the variables we are trying to juggle as we try to decide how to position things optimally. I'd love it if we could find the perfect algorithm, and I am very open to suggestions as to specifics!

The good news is, the code is pretty centralized - it's almost all handled by one function call adjustCanvasPosition(). So in theory, we just need to tweak its behavior. One catch, though, is that the function currently bases everything on one piece of information only: the particular element we want to keep in view. We don't know why that element is important, so for instance, we can't (currently) do different things for copy and paste versus note input versus just navigating with the cursor in normal mode. That's a limitation we probably would need to remove, and it's not impossible, but it is a bit of work.

As I mentioned elsewhere, it's also actually trivially easy to have this function simply do nothing if you turn off the "Pan score while playing" button, and I'm actually warming to that idea. I continue to suspect people would come to realize that having to do all adjustments themselves was more trouble than they anticipated and this would out to not be as useful as it might first seem, but I am totally open to providing the option.

Reply

• Apr 13, 2018 - 17:25

The problem with trying to keep complete bars in view comes in when the bars are wide. Keeping the next one in view might push the previous one out or vice versa, and keeping both in view may well be impossible. But I do think keeping both the previous and next notes in view is viable, and maybe adding enough of a margin so that a decent amount of the previous bar is visible as well.

Reply

• Apr 13, 2018 - 17:22

It would also be worth tracking the specific bugs or opportunities for improvement that have already been identified. Right now I am aware of the following:

1) The recently-reported regression in 2.2 where if you have vertical stacking enabled and paste to a measure that is on the right hand edge of the screen, the view pans left unnecessarily. Probably trhe same happens on operations other than paste. See #271187: Pages jump in Vertical scrolling when the score at the right is partially hidden

2) Again if you have vertical stacking enabled, we could optimize the algorithm to never pan horizontally if the full page width is in view. See #68966: Disable horizontal scrolling when zoomed to page width

To that, I would add a few things I don't see specific issues for but I think I understand pretty well:

3) we should consider adding the ability to turn off panning completely, perhaps via the existing pan button, perhaps via another means (I do worry about users accidentally enabling this and getting frustrated).

4) In note input mode, after entering a note, it would be good to try to keep both the previous and next note in view at once if possible (always possible in continuous view, "usually" possible in page view). That's something I address above, also see for instance https://musescore.org/en/node/23872#comment-760106.

5) If you first enter note input mode on a measure that is all the way to the right edge of the screen, MuseScore will pan the score to put this to the right, which I believe is because MuseScore can't tell the difference between this and cursoring backwards, and that's exactly the right behavior in the latter case. See https://musescore.org/en/node/138701#comment-707771

Reply

• Apr 13, 2018 - 17:42

Item 2 (disable horizontal scroll when in vertical mode) and item 3 - (option to disable entirely). Yes please - those would be at the top of my list for sure. I'm very happy moving the paper around with two-finger swipe and I'd like to stop MuseScore from second-guessing where I want the paper to be.

Reply

• Apr 14, 2018 - 05:27

I've been working on this today and am making good progress.

I believe I have a fix for #1, and actually, as far as I can tell, this also pretty much fixes #2 - or at least, makes it work as well as it did in 2.1, which seems to be pretty good from what I can tell. My change does not appear to break the previous fix for #117486: wrong scrolling of 2nd and subsequent pages when playing a multi-page score with vertical page layout that led to this, but I do need to do more testing to be sure there isn't some other case that would be adversely affected.

I also have a fix for #4 that works well enough for what it is. Some might say just trying to keep two notes in view still isn't enough, but it's one step better. Changing the continuous mode algorithm to try to keep full measures in view would trickier.

I have a partial fix for #5 too, and the converse case where an operation too close to the left pushes the score all the way left (I actually worded it wrong above). Neither fix is perfect in that there are still going to be cases where we either don't pan but should or do but shouldn't, but I do think my change improves things.

Finally, as I mentioned, I have a proposed fix for #3 that for now I have tied to the existing "Pan score during playback" button. I'm more ambivalent about this one, I worry that people will trigger this mode accidentally. And yet I don't love proposing a new option either. I think I'll let someone else take the reigns on this one.

Unfortunately, scrolling in continuous view seems pretty broken in master., so I can't really do my development and testing there, at least not fully. But the code really is no different and should work either way.

I plan to submit a PR for 2.3 soon, and then we'll see how it goes.

Reply

• Apr 20, 2018 - 17:52

To be clear, I didn't change anything about page view except to fix #1. That is, if you operate on a measure that comes too close to or overlaps the right border, the page will no long jump back more than necessary. Actually, in theory, there could potentially a similar bug with vertical jumping when in horizontal mode if you operate too close to the top or bottom margin, but I'm not actually sure it's possible to trigger a problem there with or without my change. So anyhow, regarding #4, there is nothing to test in page view - it's all about continuous view.

For #5, I'm confused. This should be largely fixed as I described. Only in note input mode will the score pan left, and it won't go all the way any more, it will only go to the 25% mark. When not in note input input mode, it will only move a just enough to put keep the target note in view, rather than pushing it ll the way left. That's a huge difference, should be instantly obvious. Could be we are misunderstanding each other here?

Reply

• Apr 19, 2018 - 23:06

After a bit more playing around I have what I think of as a decent set of compromises implemented in a pull request for 2.3: https://github.com/musescore/MuseScore/pull/3635

The build system produces a Windows "nightly build" package automatically even before a PR is merged, so Windows users can try out my changes here:

https://ci.appveyor.com/api/buildjobs/ydxfugd9hixf6m62/artifacts/MuseSc…

macOS and Linux users would have to try building themselves, I guess.

You should see the bug with operations near the right margin in page view with vertical stacking fixed, and also much less aggressive jumping from left to right and vice versa in continuous view. In particular, during note input, when you reach the right edge, the canvas adjusts to put the cursor about 25% from the left edge rather than all the way over, but other operations near the margins merely strive to keep the target note on screen. As a trial, I also made the "Pan score during playback" button active during all operations, so you can see if you really like moving the score by yourself all the time. If so, maybe we can design a new button for that.

Please, if you have a horse in this race - or if you don't yet but are concerned about change in general - give this a shot and share your feedback!

Reply

• Apr 19, 2018 - 23:28

After a short test of what I have seen as the most annoying jumps in continuous view this looks much more reasonable. It will take a little to get used to the new movement of the screen but after a short test it seems to be good. I will continue to use this build and let you know if I discover any bugs.

Reply

• Apr 20, 2018 - 20:42

A problem with this implementation and continuous view during playback: the score only gets panned one bar at a time during playback to keep the cursor in view. This makes for unneccessarily much panning. To reproduce:

1) Open any score at least twice as wide as your screen when in continuous view in both 2.2.1 and Marc's 2.3 build
2) Start playback in each version and observe the behaviour when the cursor reaches the right side of the screen
3) Result: in 2.2.1 the score gets panned to place the cursor near the left side of the screen, reducing the amount of times the score needs to be panned throuhout the playback.
In Marc's 2.3 build, the score gets panned to include one more bar in the view to the right each time, making for almost constant panning during playback (unoptimal and slightly annoying).

Ideally, the cursor should be panned to a position somewhere in beween the positions used in the two builds respectively.

Reply

• Apr 20, 2018 - 21:44

Ah, playback, Indeed, I wasn't thinking of that. On the other hand, we've had requests for improvements to how scrolling works there, so maybe we can improve on both the older and current behavior here. In particular, it's been suggested we scroll continuously (see #93376: Keep cursor centered during playback in Continuous View). But it was also suggested in the discussions there and in #50801: Continuous View Page Scroll that this could make it harder to follow along because everything is always moving.

I did a few tests myself, and am not sure what to think personally. Keeping it moving continuously (well, with every beat/note) is not hard, and it actually seems pleasant enough to me, but I'm not generally playing along with MuseScore during playback, so its harder for me to put myself in the place of someone form whom that is a common use case.

Keeping the current measure centered is easy but definitely seems disorienting to me personally - if you can't move smoothly, many small jumps are worse than a few big ones I think.

So maybe the best thing is to treat playback more like note entry - pan back "most" of the way to the left margin. Maybe not as far back as we do in the released versions, but more like what I do in my PR - go for 25% left.

Reply

• Apr 20, 2018 - 22:44

I don't hate it either, but I'm not a big fan either. I would prefer that if continuous scrolling is implemented, it scrolls smoothly instead of jumping with each new notated rhythm (I know this is probably not going to be that easy to implement). I would anyway prefer the current behaviour of scrolling only when neccessary to keep the cursor in view during playback, i.e. as little as possible. I do realise, however, that some people want continuous scrolling. It could be made an option, but that is looking for hundreds of forum posts about "my score suddenly scrolls with each note during playback".

Also, continuous scrolling might make sense in continuous view, but should be tempered in page view to not move the left side of the page further right than the left edge of the screen or the right edge further left than the right edge. That wouldn't make sense to me at all.

Anyway, feedback and thoughts are welcomed. Let's figure it out here before all the hard work is done ;-)

Reply

• Apr 20, 2018 - 23:55

Understood. To me, whats frustrating about the existing 2.x behavior is that it's a bit unpredictable when the jump will occur. It's based on keeping the current measure completely in view (and outside the 5% margin), but depending on the width of the measure, that could happen at different points relative to the screen. For example, in score full of whole notes, you might fit 10 measures on screen at once, and the first measure that doesn't fit might start at the 90% point or so - almost all the way to the right - so the screen doesn't jump until the cursor gets that far over, and it happens once every 10 measures. But in a score full of sixteenths, you might fit only two measures on screen at once, so the cursor will only reach the 50% mark, and the screen will jump essentially every measure. I guess I see the rationale for trying to keep a full measure in view, but in practice I'm not sure it's always a win, and in any case, it still seems the continuous scroll accomplishes the goal better.

Definitely looking forward to hearing more feedback. Making it more smooth than every note/beat is not likely to happen, BTW.

Reply

• Apr 21, 2018 - 04:05

Good point. The existing 2.x algorithm deals with this by focusing on one edge of the measure or the other. When playback hits the right margin, the canvas pans to put the left edge of the current measure at the left edge of the screen. That means if the measure is too large to fit on screen the cursor will remain off-screen. To me, this is another downside of the existing approach that continuous scrolling fixes. But FWIW, another valid fix would to simply pan back to put the cursor at the left of the screen, or the 25% point, or wherever, if we realize the measure won't fit. So that we start by trying to put the left edge of the measure to the left of the screen, but if the measure doesn't fit, we give up and just put the cursor to the left.

Reply

• Apr 21, 2018 - 01:43

>> To me, whats frustrating about the existing 2.x behavior is that it's a bit unpredictable when the jump will occur. << This. That's what bothered me most of the current (2.2.1) implementation.

>> Definitely looking forward to hearing more feedback. Making it more smooth than every note/beat is not likely to happen, BTW. << I suspected something like that. Oh well, I guess you can't have everything, can you? :-)

Reply

• Apr 22, 2018 - 06:58

Yes, that looks fine to me, well done!
One could ask for it to scroll more smoothly than this but I'm not sure what that would really mean. Because the measure widths and note spacings are variable, the X axis isn't linearly related to time (unlike the waveform view in an audio editor for example). So the scrolling speed necessarily changes with each new note. The way it moves in this example seems very natural to me.

Reply

• Apr 21, 2018 - 21:28

Another thought:

So far, I haven't noticed any comments on the "Pan score" button, and whether anyone has tried turning it off while editing and what you tink of the experience. As mentioned, I remain skeptical, but between that and the continuous scroll during playback, I have an idea. What if instead of a single toggle button, it had several different states you could choose between:

  • Pan continuously
  • Pan at margin
  • Pan during editing only
  • No pan

The first of these is the continuous pan I demoed above (for continuous mode only - in page mode it works the same as the second option). The second is the usual 2.x behavior with my additional tweaks. The third is equivalent to what happens if you turn the toggle button off in 2.x - it pans during editing but not playback (which I assume someone finds useful, although I'm still not clear on the use case). The last is for those situations where you want total control.

Reply

• Apr 21, 2018 - 23:12

Item #3 is an experimental thing I am trying in response to requests from a few people. With my build, if you turn off the "Pan score during playback" button (the one just to the left of the metronome), then MuseScore will not move the score, period. If the bar you are working on fits on screen when you start working on it, it will remain so. Of course, if the bar grows because you are adding notes, and now it doesn't fit any more, you'll need to scroll yourself. That's the whole idea - some people have said they don't want MuseScore scrolling for them. This option is for them, but I have no idea if any of those people are reading this or if they'll end up actually liking it or if they'll find it annoying to have to always o all the movement themselves.

Reply

• Apr 23, 2018 - 22:27

Someone with a Mac build environment going is more than welcome to build my branch and make that available for testing, but as mentioned, there is nothing I can do.

However, I don't think any of the changes I made in any way are affected by the input device. I didn't touch the code that handles input from the user one bit. it's only the automatic panning behavior that is changed here, and that is completely device-independent.

Reply

• Apr 22, 2018 - 07:08

I also don't get the utility of "pan during editing but not playback". An option that I'd find useful is the opposite of that: "pan during playback but not during editing".

Actually I think your idea of incorporating this behaviour into what is now the "pan score during playback" button is a simple and elegant solution. It would redefine that function to be simply "auto-pan on/off" and it would apply to both editing and playback.

Reply

• Apr 30, 2018 - 18:04

My changes were merged, as have other related changes by Matt McClinch so currently nightly builds for 2.3 should show some new behaviors:

a) the bug where the score jumps when operating near the right margin in vertical stacking mode is fixed
b) a new option is provided to prevent you from accidentally scrolling your score away from the margin (this is what Matt provided)
c) when operating near the left margin in continuous view, the score will no longer jump all the way to the right but only just enough to keep the edit in view
d) when operating near the right margin in continuous view, the score will jump only to the 25% point during note entry rather than all the way to the left, and other editing operations will jump only enough to keep the edit in view
e) the "pan score" button will now be honored during editing as well as playback, so if you prefer to do all scrolling yourself, you can
f) during playback in continuous mode, the jump to the left will happen only when the cursor reaches the right margin rather than a full measure-width away from it

The last of these is the only one I personally still have doubts about. It means less jumping, which from my perspective using playback as a check to my work is an improvement. Someone actually trying to play along with the score might prefer more jumping for read-ahead purposes, although I think this use case is better served by a continuous scroll such as I demoed above. I left the code in for that but it's disabled; it would be very simple to enable it either in all cases or via an option of some kind.

Reply

• May 1, 2018 - 17:47

Indeed, as I mentioned, when using MuseScore as a playalong tool rather than as a notation tool, something like the continuous scroll I implemented but disabled would probably be preferable. Since the primary purpose of MuseScore is notation and not playalong, hopefully its the right call in general, but if someone wants to pick up this idea and implement the continuous scroll as an option, I totally support that.

Reply

• May 1, 2018 - 23:35

Seems to me in continuous view when scrolling with playback: the cursor should progress from the left edge of the window until it reaches the middle of the window. Then the cursor should stay in the centre of the window while the page scrolls to the left; and finally at the end when the paper runs out the page will stop and the cursor will continue to move until it reaches the right edge of the screen. Something like that anyhow.

Reply

• Jul 24, 2018 - 20:04

I use MuseScore quite often as a play-along tool, especially so as it helps substantially when gaining speed, practising difficult passages ,checking additionally entered voices, etc. So this playalong oriented mode would substantially help in "collateral" notation work. I don't want to print a score every time I'd like to check for its playability etc.

I wouldn't mind if this feature is provided in the songbook/app version, but without it in the MuseScore universe there is definitely something missing. Or is there any application that takes original MuseScore files and provides this feature?

Btw, such an enhanced playalong mode would certainly gain from a linearized display: Resolve jumps, repeats and such (sensible for a printed score!) automagically in a straight-through moving score display.

Petra

Reply

• Jul 24, 2018 - 20:48

Another user shortly reported about the app "piascore": https://musescore.org/en/node/274543.
I don't have installed this app, but it seems there's a continious scrolling mode - not from left to right, but from up to down (and maybe you've export the MuseScore file to PDF before).

As mentioned from other, first of all I would like to see such a feature inside the songbook player, and above, but secondary it's necessary inside the MuseScore notation application for me.

Concerning your last sentence/request: It isn't yet implemented, but I believe, I read such a discussion before about this topic, unfortunately I can't find it again.

Reply

• Jul 25, 2018 - 19:22

Thanks a lot for this pointer! Seems there are other people that think about it and would value it the same way as i do.

Indeed, the unroll feature is a mandatory precursor for the additionally envisioned, left-oriented continuous scroll feature for playalong sessions.

Kind regards,
Petra

Reply

• Aug 14, 2018 - 08:31

Hi Marc,

regarding your f) point we had a thorough discussion yesterday within a group of 3 MS hobbyist users, with special consideration of the playalong issue in practising or even getting rid of heavy score binders to be carried to practising meetings.

I guess there are three issues to be met: i) the expectable progression of a (linearly continuous) score, ii) the play position pointer display, and iii) the requirement to look ahead to brace for upcoming difficulties.

Regarding i), I did not really like your implementation shown in your video, as the "continuous" progression of the score is jumping, making it hard to reposition my eyes to the respective "score neighbourhood" that I need to interpret in order to play the upcoming notes correctly. Here a really continuous scroll of the score (potentially slowly changing in absolute scroll speed when a series of 16th is being played) would be more appropriate IMHO. That way the eye gets accustomed to the continuous flow without a continuous and stressy need for constant hard view angle jumps.

ii) The play position pointer could be related to a smooth continuous score flow in the ordinary jumpy way in a relative fashion, quite similar to its present display in page or continuous mode: In playalong mode it is perceived more or less subliminally (at least in my notion), helping to reposition the focus, but just a few milliseconds behind the required intonation of own notes anyway.

iii) When we talk about electronic displays being used in playalong mode we should not adhere to the form factors of the past: I do not feel the necessity to copy with 7" tablets (or even smartphone displays) for score rendering. With 10" tablets or larger a couple of bars should show up in an appropriate size, even for busy passages. IMHO, the measure to relate to when defining the display approach should be the relative complexity of the piece to play along to: At least from my hobbyist point of view there is no need to keep an eye on a range of more than, say, 25 individual notes, regardless if they are fulls or 16ths. This "magnification" should be easily obtainable with 10" display or above?

Using displays of 12" diameter or larger there might be even another mode that would even be more pleasant to view: Using a continuously scrolling page view of an otherwise linearized repetition mode. Such displays are able to render more or less a full printed sheet in a sensible resolution and size. A rather slow scroll through several systems of an habitually displayed score sheet should be quite pleasant to the eye of the playalonger, and w/r/to implementation approach quite similar to the already existing page view mode, but without the problem of no preview at the end of the current score sheet, if the average current position is kept in the upper half of the display.

Kind regards,
Petra

Reply

• Aug 19, 2018 - 21:06

Thanks for your comments. Realistically, doing what I did - scrolling note by note rather than a true "continuous" scrolling - was very simple to implement; making a smoother scrolling would be much much much more involved. Probably something more likely to be tackled in the mobile app, which is more geared for that type of usage, than in the notation program.

Reply

• Aug 20, 2018 - 07:11

How happy would you be reading a book if it scrolled by word by word like the subtext on a TV newscast?
An input from the point of view of live performance:
1. It's very uncomfortable and disorienting to have only a small section of the score visible at a time - and even more so if that section is in constant motion. Eyes look away to the instrument or to the leader, need to know where to come back to - that's disrupted if the score is moving.
2. The performer is accustomed to viewing the notes in the context of the score around it, which means having many measures in view. It's a matter of noticing the shape of the score, to be aware of similarities in phrases, seeing where the flow is going to etc.
3. The performer wants to be in control of where they are looking on the screen, which means they want to be able to position the score fast and intuitively (and not automatically: what if the tempo changes?) - typically with Bluetooth foot switch.
4. The above points are especially strong in rehearsal, where the performer wants to quickly jump forward or back to a particular bar or section under the direction of the rehearsal leader.

Reply

Do you still have an unanswered question? Please log in first to post your question.