Screen skipping ahead

• Oct 25, 2016 - 01:27

I didn't find anything in the help files on this so may be asking the wrong question. My problem: I'm working on a choral arrangement- SATB with solo-. I entered the melody first and am adding the harmony now.
When I add a whole note in the bass line the score skips ahead to the next measure hiding the measure I'm working on so I have to scroll back to enter each voice in the measure. Can you help me avoid this annoying behavior?


Over the years this has been commented on so many times, by me as well as many others. The annoyance has consistently been under-appreciated and basically ignored.

It seems to me that it would ease a lot of frustration if there was some manner to deal with it.

I admit that I have no understanding of the difficulty in implementing a "fix", but I have a suggestion. Maybe it's possible?

Is there no way to assign a modifier key or set (such as, for example Ctrl,Alt, Shift) that would inform MS that since it is in the last bar of a displayed screen, to lock on that screen as long as those modifier keys are pressed? At the same time, it would need to allow many if not most of the common operations in that bar (note entry/edit, etc.).


In reply to by xavierjazz

Changing the behavior is not difficult. The problem is that the current behavior is what most people want most of the time. The number of times one would *not* want the cursor to automatically advance is very small compared to the number of times you *do*. So if we changed the behavior, it might help these few cases but would make the usual case where one *does* want the cursor to advance much worse.

So the trick is coming up with something that allows users concerned with this particular case to get what they want in these cases *without* inconveniencing the majority of users the majority of the time. Some special keyboard modifier is indeed possible, but most combinations are already taken.

In reply to by xavierjazz

Yes, and realize my response was also directed at the OP, who probably had not seen those earlier discussions.

Anyhow, like I said, we're pretty much out of modifiers, especially when you consider that we'd basically need to duplicate dozens of note input commands to provide alternate versions. I'm not sure it's practical. Might make sense to brainstorm other ways of doing this.

In reply to by Marc Sabatella

Then I suggest having a toggle option that forbids the pan and cursor from moving to the next page when the last rest of the final bar of a page is filled (someone who wishes to proceed to the next page can just use arrow keys).
This makes mass music engraving so much easier (and Musescore more complete!)

In reply to by Marc Sabatella

Automatic page scrolling is the most annoying feature of many programs, both notation and DAWS. It wastes a huge amount of time and causes intense annoyance. So why do many people require this? I believe that the difference off opinion is due to the fact that many writers approach scoring as an extension of live performance and, when inputting in real time, of course the auto scrolling will be useful BUT most orchestral work ranges from difficult to impossible to input in real time so that being able to dwell on the last bar of a page until it is complete is essential. Please, please, please change this feature.

Not only this, but I've had my screen jump to the bottom of the page while adding notes instead of just skipping to the next measure. This especially occurs when I'm zoomed in within page view. This also happens during playback. I took a gif capture to illustrate this: it requires a zooming out in order to see what's playing.

Attachment Size
out.gif 240.03 KB

I know this is an old thread but I do similar things and the moving of the cursor (current note input point) does not bother me because pressing the back arrow will move the cursor to the previous note. If you either click the voice 2 button or press ctrl-alt-2 your input changes to voice 2. Note that the 2 may be replaced with any number from 1 to 4. If you know the note you want to enter, then the screen will return to where you can see it. This isn't ideal but is faster than picking up the mouse, scrolling or dragging the display, putting the mouse down and finding you finger spots on the keyboard and remembering what you wanted to write. I find it more convenient to just type something like back arrow, ctrl-alt-2, 4, A, Backspace so I can see where I was. Just don't replace that 4 with a note length that takes up the entire measure. Been there, done that, and wasn't happy with myself.

In reply to by mike320

This is indeed something that happens all the time. When you enter the last note of a measure it disappears immediately. If you want to make sure it is in the correct octave you have to move the cursor back. I for one move the cursor back routinely to make sure.
Why can't the measure one works on be in the middle of the screen rather than at the very left edge? The real estate before you that is as yet empty is not that interesting, is it? I think the cursor movement is just fine, but why snatch away the finished measure before the "Musescorer" has a chance to have a look at it?
Are you always absolutely certain your last note was correctly entered, Marc? I believe most people aren't.

In reply to by azumbrunn

I suspect the reasoning is, the further left the score is moved, the more room there is to the right, and therefore the longer you can go before the view needs to be shifted again. The assumption being, it is better to minimize the number of jumps. Probably different people would have different preferences here depending on their working methods and type of music they are working with.

As for whether or not I am always certain the note I entered is correct, I hear the playback, it tells me what I need. I seldom look at the screen while entering music any more than I do while typing. If I ever do need to look back, I can always hit the left arrow. But I'm almost always more focused on what I am about to enter, not what I already entered. Your mileage may vary :-)

In reply to by azumbrunn

I admit that I turned off the "instant playback" of newly entered notes long ago because the constant beeping annoyed me. I had almost forgotten I ever did that. I guess you get to choose your evil: Either you can hear if your entry (of notes at least) was correct and you get annoyed or else you don't get annoyed but you have to check optically for correctness.

My fault.

On the other hand: I usually enter slurs with the shortcut "s", e.g. "s-note-note-s-s-note-note-s" etc. It seems the fastest way to do this. But if one forgets one of those s'es the whole sequence is messed up. Without optical control one can easily miss this. Also the double tap on the touchpad for palette elements does not always "catch". If I don't see the note I can't be sure the "f" is actually there. Double click on a mouse is safer, but even there if you miss the "rhythm" you can fail.

In reply to by xavierjazz

Yes, the thread is about note entry, but the point is that whether or not one has playback enabled has a direct bearing on how one feels about the current scrolling behavior. People who have playback *disabled* are more likely to want to see the note they just entered *even if they are done with that measure*, because they want to look to see if they entered it correctly. Whereas people who have playback *enabled* are more likely to be confident they entered the note correctly because playback made this clear already.

Aside from that, though, another difference has to do with how often one tends to do further work in a measure after entering the last note of voice 1. People who enter a lot of articulations or other markings measure by measure as they go rather than entering those markings in a separate pass later are more likely to want to keep the previous measure in view even after entering the last note of the measure. Also, people who work in multiple voices a lot are also more likely to want to keep the measure in view.

That is why I keep observing that there is not going to be any universal agreement about what the "best" behavior is - too much depends on people's personal work habits. So again it comes down to figuring out what the best *compromise* is, knowing full well that no matter what is implemented, a significant number of people will find it not ideal.

In reply to by Marc Sabatella

Two things:

- There seems to be confusion about playback. In this context it means the little beep that confirms the pitch upon note entry and can be enabled or disabled according to preference. The sort of playback that plays the whole piece is something different and does not have to be enabled or disabled. You just listen to it when you think it is a good idea.
- Personally I like to enter notes and markings in one go--especially the markings that have a shortcut assigned to them (slurs, staccato dots, hair pins). I think if I were a composer I'd do it like Marc. But if you e.g. try to assemble a score from a set of parts you have to focus on your source as well as on the screen and I for one just don't pay enough attention to the little beep for it to be of any help. Especially as there are things that the beep won't tell you or not with certainty: Is the slur correctly placed? Did I indeed put in a piano or did I err when picking it up from the palette? Etc.

As to the optimal window: How about letting the system move forward after the second note of the new measure is entered? That way the maximum you'd see is one measure plus two notes; only two notes more on the left side (and two less on the right) than the present state of affairs. For me that would be sufficient and maybe for many others too.

In reply to by azumbrunn

Re: "As to the optimal window: How about letting the system move forward after the second note of the new measure is entered?": unless I misunderstand, that just delays the "jarring" move by one entry.

I much prefer the "keep the worked-on bar in view (perhaps as the first bar on screen)" until released mode myself.

Suddenly, as I type, I understand a difficulty with this, as MS must handle pages and systems as complete entities rather that being able to parse to a finer (say, measure) level.

In reply to by xavierjazz

I just tried it again and found that continuous view and page view behave differently.

Continuous view lets you fill the bars across the screen, then jumps keeping 2 or 3 of the entered notes in sight. I never work in continuous view because it renders the navigator practically useless, but as far as seeing the last few notes I entered this seems fine to me.

Page view on the other hand jumps to the next line or page the millisecond the last note is entered forcing the user to scroll back to see the last measure. The problem here is that it depends on your systems what the optimal solution would be. If you have one staff systems and the whole page width inside the screen things are mostly fine since you get a page jump only every 60 measures or so. But if you have a one system per page score you get those page jumps that obscure the prior measure every 4 or 5 measures and it gets annoying.

But what to do about it is unclear to me: There are all conceivable intermediate cases. So the proposal to allow the user to "release" the jump is the only one left. Only some people would probably find that annoying too.

In reply to by azumbrunn

Just throwing in that in page view, having the pages flow vertically could help in keeping things in view. Only if your pages are flowed horizontally, there's a real gap between where you currently are and the position just before/after it.

In reply to by jeetee

There is one reason why having screen control while entering notes and measure text etc is very important and not having Musescore jump about, which I believe is the subject of this thread. If you are transcribing from a complex music score pdf into Musescore, being able to split the screen and keep the pdf measures displayed in the original file in synchrony with the measures in Musescore, one above the other, is critical to accurate and easy transcribing. Especially if the original PDF doesn't have measure numbers. I am a member of IMSLP and the new collaboration with Musescore may make this functionality demanded much more. I have tried this technique of transcribing and the first few bars of any transcription is easy until you get to the point that Musescore starts to jump about when it becomes really difficult whether in Page view or Continuous view. Kind regards, Michael.

In reply to by rch_m

If you have a specific suggestion for how MuseScore should position its view differently, feelnfree to make a proposal. As already explained, MuseScore normally assumes that after entering a note, the next most likely thing you will want to do is enter another note after this one. And that is why it sometimes need to reposition. If you are saying you work in a more random fashion, so you do not in fact normally go left to right, then not repositioning could indeed make sense. But it doesn't really sound like that is what you are saying. Maybe you are saying you'd prefer the cursor simply move off screen so you can then move the view yourself, and then manually move then PDF by the same amount?

In reply to by rch_m

BTW, there is an experimental "transcription mode" that was under development at one time for MuseScore 3, and I think the diea was to keep a split screen view showing the PDF and the score being worked on simultaneously and always in sync, so moving one moved the other. Sounds like that could be useful as well for this particular type of application. Not sure of the status of that work.

In reply to by Marc Sabatella

This idea of working with the Pdf and Musescore open is already doable; certainly on MacOS but I believe on the other OSs also.

The problem is that you have to restrict both files to a very small area, forcing MS to reposition very often--and also making it harder know where you are on the Pdf. Or else you make everything tiny, making using the mouse a tricky precision task and making reading the notes on both files very tiring to the eyes. So I generally prefer to memorize about a measure at a time and then to enter it going forward and backward between the files.

For a little while I had the luxury of having two screens connected, the TV and the screen of the laptop, but then we moved and the TV was in an unsuitable location and I don't want to carry it around all the time. But if you can use two screens for the two files it is quite comfortable.

BTW I have never actually seen MS "jump around". It just "jumps" forward when it jumps at all.

In reply to by azumbrunn

Thanks for your replies. I have taken some screen shots to show what happens. The screen shows the pdf primo score in Foxit in the upper half of a score fo 4 hands. Measure 98 is at the beginning of the line. In the lower half of the screen there is Musescore page in continuous mode, and I have lined up measure 98 similarly so that it is easy for transcribing. I have transcribed the right hand score to measure 105. I now want to start to enter the left hand into the lower staff in measure 98. I have selected the measure as seen by the blue box and both original measure 98 and the musescore bar 98 are reasonably together. However as soon as I select Note input either using the icon or pressing 'N' in Musescore, Bar 98 moves to the far right of the screen which can be seen in the second shot Screen Shot 05-02-17 at 12.32 AM 001.JPG The only difference between these two shots is that I have chosen note entry. This has caused me errors and time wasting especially when there are several similar bars in the sequence.


In reply to by rch_m

Hmm, I agree that doesn't make sense. I find I can reproduce this occasionally if the measure I am starting with is to the very left edge of the screen. it doesn't make sense to me either, but it doesn't happen if your start with the measure just a little further right, so that at least is a workaround.

Meanwhile, I will see if I can figure out why this is happening, because as far as I know it shouldn't.

In reply to by rch_m

The code responsible for this is here:…

We are testing to see if the cursor position is close to the left edge of the screen (within 5% of the width of the screen). If so, we reposition the view to put the cursor closer to the right edge.

So indeed, we are deliberately doing exactly what you see here. The question is, why? I have a theory. I'm thinking this code was really intended to come in to play while cursoring backwards through the score. So when you reach the left edge of the screen, the view moves right so you can continue cursoring. I doubt this was ever meant to kick in when first entering note input mode.

Not sure the best way to deal with this. Perhaps we pass another parameter to adjustCanvasPosition() to indicate whether we are in fact moving backwards through score, and only execute this bit of code in that case. Not sure. But thanks for the clear example - hopefully it allows us to improve this!

Meanwhile, what I said above definitely holds regarding a workaround - just don't start *quite* so close to the left edge of the screen, and you should be OK.

In reply to by Marc Sabatella

Thanks so much Marc, interesting. Your work around works to a point. I tested it to find it only works if the measure preceding the active measure I want to enter notes in, ie measure 97 in my screen shot, is fully on the screen ie the first bar line of that preceding measure is visible. However if the preceding measure is complex ie longer, this means the distance from the left side to the bar I am wanting to enter notes in is variable though the trigger for re-formatting appears fixed. So the rule must be selecting the previous measure? I don't think I would have ever discovered this because I was always positioning the relevant bar in Musescore to be as close to the left side as possible. Is it anything to do with the system text (tempo, primo, clef, time signature) that appears in blue on the left side of the continuous score view?

In reply to by rch_m

Marc, you are right. I created a long measure and it is the distance from the left margin that is the trigger. I originally had a test measure that just happened to trigger when the left hand bar line of the preceding measure was in view! Michael

In reply to by rch_m

Dear Marc,

I have now identified some inconsistencies in the behaviour of Musescore during formatting. If the user is managing objects in the score and not in note entry mode eg changing shape, size, anchor point of objects like slurs, ties etc. the object will be highlighted in blue. If the user then selects note entry mode, musescore relocates by different rules to new note locations - in the worst case scenario this is to the note at the beginning of the score - which is very confusing in a long score.

In all cases the objects referred to below would be showing highlighted in blue and the resulting position on reentering Note mode is described

object selected ie highlighted in blue and relocation position on selecting note entry:

All Lines (8va line, cresc) -> begining of score (
Tie -> begining of score ( Why not one go to one of the notes
Slur -> begining of score ( which anchors these
Beam -> begining of score (
Hairpin -> begining of score (

note stem -> first note in bar even if the stem is on the eighth note in a bar ie. not the note to which the stem is attached to which would be the logical action.

Text (stave & system) -> note to which text is anchored to
articulations -> note to which articulation is anchored to
dynamics -> note to which dynamic is anchored to
bar number -> first note of same bar

The only work around is to ensure after any editing the the user has highlighted a note to return to after editing - a bit clumsy and a real pain if the user forgets.

Surely the rules that apply to Text, articulations, dynamics etc which work well could be applied to the ones that return to the beginning of the score?

I haven't tested all objects but this would be worth working on because the behaviour of Musescore may not be obvious to new users.


In reply to by rch_m

I'm not sure I understand what you mean. If you are saying, you neglected to select a note or measure before entering note input, it is true MuseScore has to guess which note you actually meant, and we may indeed guess differently than what you may have wanted. That's why it is best to actually select the note or measure and why the documentation specifically says to do that.

But do be sure to have the latest version of MuseScore (2.1). We do continually improve the guessing algorithm. I'm sure there is room for further improvement, so feel free to start a new discussion in the Feature Request forum. But keep in mind, you really are supposed to select a note or measure, not some other object.

In reply to by Marc Sabatella

Marc, I agree that for best accuracy the note should be selected prior to entering Note mode. However it is easy to forget to do this when you have been editing objects for some time. So in all the scenarios I tested I highlighted an object did not select a note to see what selection Musescore made on re-entering note mode.

There appears to be at least 2 "Guessing algorithms' in operation here and one is much superior to the other. 1) If you are editing text, articulations, dynamics etc if you haven't selected a note, the algorithm takes you pretty close to the position in the score that you are working on usually the same bar. 2) However if you are editing lines (slurs, Hairpins, octaves [8----- ] and ties, and a note is not selected after editing, on changing to Note entry mode Musescore selects the very first note in the score and moves the display to this point which is a very poor choice.

All I was suggesting that if a note isn't selected the outcome in Musescore should be more like the first for all scenarios than the second algorithm.
I am using Musescore 2.0.3.
Best wishes,

In reply to by rch_m

As I said, I agree the guessing could be improved further. I'm simply asking you start a new thread to discuss this, so the suggestion doesn't get lost among the many unrelated comments in this thread.

For the record, it's not that there are two algorithms: there is only one, and it is based on the 'parent" of the selected object in the underlying code. The problem is that certain elements have parents that are not conducive to this approach, so we should probably special case them. That is why a separate discussion makes sense to identify which elements need special casing, and what that special handling should be for each. And again, a separate thread dedicated to that specific topic is the best place to do this.

I've been annoyed by this problem for awhile as well, as I often write chords out and have to back scroll every time to add the other notes. Reading through all these suggestions I thought of a solution that, though still a little annoying, might be less annoying than the original problem: If you want to add a chord at the end of a measure, just make the last chord shorter than the remaining beats in the measure.

For example, to make a measure of a whole-note C chord, input your C, E, and G as half notes. That will leave a half rest at the end and you can just change the chord to a whole note (highlight one or all notes when not in note-entering mode and select whole note) when you're done. Again, sorta annoying, but maybe quicker?

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