Screen skipping ahead
Hi,
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?
Comments
BTW- i have tried both continuous and page view with the same problem.
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.).
Regards,
In reply to Over the years this has been 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 Changing the behavior is not by Marc Sabatella
I understand, therefore my thought about modifier(s).
In reply to I understand, therefore my 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 Yes, and realize my response by Marc Sabatella
If it is possible to have 2 states: move to next note/measure - do not move (until released), it may not need so many " ... dozens of note input commands to provide alternate versions".
In reply to Yes, and realize my response by Marc Sabatella
Why not add a toggle option in Preferences->Note Input something like 'Disable automatic pan while adding notes'?
In reply to Why not add a toggle option by Ragokyo
One question is whether it is really about the panning (moving the score to follow the cursor) or if it is more fundamentally about the cursor moving in the first place.
In reply to One question is whether it is 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 Changing the behavior is not 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.
In reply to Not only this, but I've had by worldwideweary
That appears to be unrelated - this is playback, not note input. But it does appear to be a bug. if you have precise steps to reproduce, please open a bug report.
I'll post a topic with two more attachments
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 I know this is an old thread 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 This is indeed something that 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 This is indeed something that by azumbrunn
Amen! Put the current measure in the middle rather than flush left.
In reply to This is indeed something that 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 I admit that I turned off the by azumbrunn
I also never use the playback capabilities of MS.
Moving to the middle is perhaps too disruptive as already noted, but I would like to see the general idea implemented.
I would appreciate it if bar I was just working on remained onscreen.
In reply to I also never use the playback by xavierjazz
In my opinion none of this discussion has to do with playback, only with note entry. The way playback scrolls or not is fine the way it is.
In reply to In my opinion none of this by mike320
That is correct.
If you read the original post, it is about note entry.
In reply to That is correct. If you read 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 Yes, the thread is about note 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 Two things: - There seems 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 Re: "As to the optimal 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 I just tried it again and 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 Just throwing in that in page by jeetee
Hi,
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 Hi, There is one reason why 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 Hi, There is one reason why 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 BTW, there is an experimental 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 This idea of working with the 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]( "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.
Michael
In reply to Thanks for your replies. I 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 Thanks for your replies. I by rch_m
The code responsible for this is here:
https://github.com/musescore/MuseScore/blob/2.1/mscore/scoreview.cpp#L4…
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 The code responsible for this 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?
Michael
In reply to Thanks so much Marc, 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 Marc, you are right. I 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.
Michael
In reply to Dear Marc, I have now 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 I'm not sure I understand 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,
Michael
In reply to Marc, I agree that for best 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.
In reply to As I said, I agree the by Marc Sabatella
will do.
Michael
Try to fit the page to the screen.
On my system, 75% zoom is enough.
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?
In reply to I've been annoyed by this by Bakeacake08
As noted above, simply using Continuous View eliminates the need for this completely. As does entering notes via keyboard shortcut (eg, press Shift+A to add an A to your chord). You never need to scroll back just to add notes to a chord.