"Beginning of score" button doesn't move the display

• Apr 21, 2015 - 12:47

The "beginning of score" double-arrow in the toolbar used to (before 2.0.0) move the display to the beginning of the score as well as setting the invisible playback cursor to that point. Now it only does the latter. This seems to be a lot less useful. Was this change intentional, and if not, can the earlier behavior be restored? Thanks.

Comments

• Apr 21, 2015 - 14:40

It's not really a "beginning of score" button. It's a "rewind" button, relevant only for playback. And it does performs that function - during playback, which is the only time it is really intended to be relevant. If you simply want to position the *view* of the score, that isn't the right button to use. And indeed, it wasn't in 1.3 either, although perhaps some bug caused it to occasionally have that effect in some specific case (I can't reproduce that on 1.3). Instead, to position the score view, simply use the standard keyboard shortcuts - eg, Home, Ctrl+Home, PageUp, etc.

Reply

• Apr 21, 2015 - 15:45

Ah, so it did do it on occasion, but you consider it a bug. It is not "only relevant during playback"; it positions for the next playback, and that's the only way I use it, i.e., immediately prior to starting playback; I always want to see the place where playback is going to begin. This should be conditional on "pan score during playback" mode; I think it is implied by it.

Reply

• Apr 21, 2015 - 19:11

I was being somewhat facetious in calling it a bug. It's probably more appropriate to say, it something bug if it behaves in unpredictable ways. In both 1.3 and in 2.0, the button always achieves its primary purpose - resetting the *playback* cursor. But in 1.3, this would "sometimes" cause the score view to follow even though you are not in playback mode, and sometimes not. To me, that is a bug, although a minor one. I personally never saw rewind reset the score view, but then, I rarely use that button - I use Home to reposition the score.

The point, though, is that "Rewind" is a plyabck command. The playback toolbar doens't provide a full set of score view positioning commands because it isn't meant to be used for that purpose. It provides commands relevant for playback, not for score view positioning. A separate toolbar with Home, End, Page Up, and Page Down commands might be a useful thing - especially for people on Macs or Chromebooks or other keyboards that lack those keys. But I don't really any obvious reason why "rewind" should automatically also do a "home" any more than the reverse.

Reply

• Apr 21, 2015 - 19:30

Can you see an obvious reason why it shouldn't go back to the beginning? That is the behaviour I intuitively expected when I started using MuseScore. If, as you said before, the rewind button is only relevant to playback then a press of "rewind" will always be followed by a press of "play", and that will move the view back to the beginning. I appreciate that "rewind" was originally intended for playback only, but this seems like an opportunity to get it to fulfil an additional purpose as a "home" button without having a negative impact on the way anyone currently uses MuseScore. Unless you can think of a situation where a press of "rewind" is not immediately followed by a press of "play"?

Reply

• Apr 21, 2015 - 19:57

I do suspect you would usually press Play after Rewind. So no, I don't see the *harm* in this, and wouldn't *oppose* a change. But I also don't think it's the right solution to what I assuem the real problem is - people wanting to navigate. I don't like the idea of ecnouraging people to use playback functions as substitutes for score navigation. Next someone will want a Fast Forward button that positions the score added to the Transport toolbar, but this makes no sense. And what about other navigation commands that would be desired - page forward and back? I'd rather solve the real poblem here - making score navigation easier - than worry about what sort of tricks might allow unrelated functions to have the side effect of what you really want but only for the specific cases that happen to map meaningfully to the Transport toolbar.

Reply

• Apr 21, 2015 - 20:17

No. Every time I use it, it is to play from the beginning (because that's all it does). And I say, "Arggh! Why can't it put me there, too?" If I had a "home" button, I would have to press two buttons, or ask that the "home" button rewind the playback, too. The two functions are closely related, not coincidental.

Reply

• Apr 21, 2015 - 21:11

We are talking about two different problems. You are talking about someone who actually is interested in playback. For that person, yes, they are likely to hit Play after Rewind - because that was their *reason* for pressing Rewind in the first place. I, on the other hand, am talking about someone who may have no interest in playback whatsoever, but is hitting Rewind because they don't know how else to position the score at the beginning.

For your case, there really is no problem. You don't have to hit Home - it already homes itself when playback begins. And you said yourself, that's the next thing you were going to do anyhow. So it's at best a very minor nuisance that it doesn't do it until a second or two *after* you hit Rewind (or however long it takes you to get around to pressing Play). Personally, I don't mind the extra "think" time still looking at where I am. Again, I have nothing against changing this, but it seems inconsequential to me, and misses the *real* problem.

The *real* problem is the second case - the person hitting Rewind because it's the only way they can figure out how to get back to the beginning of the score. Even if we tweaked the behavior of Rewind, it doesn't solve their general navigation problems. To me, those are the real problems that need solving. If we tweak Rewind, fine, whatever, but it doesn't address the actual problem with the discoverability of navigation functions, especially for users with no Home and End keys.

Reply

• Apr 21, 2015 - 22:28

I'm not sure whether this was a reply to me or to BSG, but I agree with both points you made, Marc. If you are about to click "play" anyway then it doesn't matter that the view didn't reset when you clicked "rewind". I also agree that there need to be dedicated navigation buttons (or that the existing use of "Home", "End" etc. needs to be publicised better for new users).

However, I still think that the score view should reset when you click "rewind". It seems much more intuitive to me, not least because currently nothing (visible) happens when you click it. Perhaps if there was a visible playback marker that moved when you click "rewind" (like in Audacity) then the current behaviour would make sense, but even in Audacity clicking "rewind" resets the view as well as the playback marker.

Reply

• Apr 21, 2015 - 21:02

The "play" button moves the display, so it seems to me that it would make sense for the "rewind" button to move the display too (providing the "Pan score during playback" button is selected, of course!). Perhaps the way forward should be: playback controls always affect navigation (if "pan" is selected), but navigation controls never affect playback.

A separate (but related) issue is the fact that the playback marker is not visible when the score is not being played. There have been countless occasions that I have edited a score and then pressed "play" expecting it to play what I was looking at, only to have it jump to wherever it finished playing last time. If the playback marker was always visible then the effect of playback vs. navigation controls would be clear. Currently, unless you remember to click a note first, you just have to pray that the playback will start from the right place and you won't be whisked away to another part of the score.

Reply

• Apr 21, 2015 - 16:21

Marc, I occasionally find that 2.0 has gotten into a state where the standard navigation keys don't work correctly in Continuous View. I can't give you a complete description of the behavior (I should have made detailed notes when it happened, but didn't), but I can say that the PgUp, PgDn and Home keys stop behaving as they usually do. In particular, the End key returns to the beginning (!) of the score.

I've only seen this with one of my scores, but it's the one I've been spending most of my time on, so that needn't mean anything.

Is this a known problem? If not, I'll stay on the lookout for this behavior and try to furnish a better description the next time it happens.

Reply

• Apr 21, 2015 - 19:10

No, I've never heard of this, so indeed, if you figure out a way to reproduce it, that would be worth noting.

I guess if you are in Edit mode - for a text element, say, or an articulation - the navigation keys don't affect the score view. And if you were in text edit mode for the title and didn't realize it and scrolled away from the first, then hit End, it would move the cursor to the end of the title, which might result in the score view being repositioned back to the first page. That's the only type of case I could think of where you might see something like what you describe, but that would be normal behavior I think.

Reply

• Jul 31, 2018 - 13:17

I know this thread is about 3 1/2 years old but i have to say that I agree with BSG and shoogle. It may not be the software author's original intention that the rewind button should also move the score but it seems intuitive to me that it would do that. Especially, as previously noted, playback moves it.

I also always have an 'arrrrgh' moment when I click rewind and nothing appears to happen. Personally, I want to see what is going to be played next, as I can when MuseScore is playing. As a software user, I don't like clicking on things and having no confirmation that anything changed.

Possible other ways of potentially achieving what I would prefer:
A 'play from start' key-press
The view to change to include the note that is about to play, rather than the one that is currently playing (might have the same effect). Probably when a play related command is issued by the user.

I realise I'm not the one writing the software (although I am a software writer and I am extremely impressed by MuseScore - thank you) and I don't know how much of a problem it is to implement. All I know is that, as a user, I have never once pressed rewind and not expected/wanted the view to change back to the beginning.

As it happens, I would also love functions that rewinds (and changes the view) to a rehearsal mark. Maybe even just the previous rehearsal mark.

Reply

• Jul 31, 2018 - 15:18

The problem is exactly that. Sometimes it jumps back, sometimes it doesn't - it depends which mode you're in.
As a user who sometimes plays along with a real instrument, I'd like to press rewind, have the score ready for me to view, then press play.
As a user who sometimes composes, I never want to press rewind and have it leave the display showing bars 80 - 110.

Personally I never want to rewind without it showing me the start of the score.

Reply

• Jul 31, 2018 - 15:50

No need to do it while playing back, doing it before playing back also jumps, at playback start
The Input cursor BTW also remains where it is on pressing Home.
These are simply 2 different buttons for 2 different purposes and no, they should not do the same thing

Going a step further: what should PageUp/PageDown do, playback wise? Maybe move to next/prev page , but where exactly, first measure, last measure?

Reply

• Jul 31, 2018 - 16:07

Probably not last measure. If you're asking, first measure would make more sense but as pages boundaries are usually a bit arbitrary in the music (for example it changes with concert pitch on/off) I would favour going to the previous/next rehearsal mark.

And again not limited to play mode. I would like rewind to rewind the view and playback pointer to the start and page-up/down to do the same the the rehearsal marks.

Space is fine to play as it's easy to reach.

Reply

• Jul 31, 2018 - 16:58

The thing is, it is two different jobs. One has to do with playback, the other has to do with navigating your score. It is pretty rare that I would want to interfere with anything having to do with playback just because I happen to be navigating in the score. On the other hand, it is is pretty common that I'd want to to see the score navigate according to playback. And the few times I don't - like I want to hear playback while continuing to focus on one area of the score - I probably wouldn't want the score moving at all, not just on pressing rewind, but also not following the cursor during playbac

So here's my simple proposal:

  • keep the existing behavior of Home et al exactly as it is - this affects the score view only but not playback, just like scrolling, just like dragging the canvas, just like page up/down, just like every other form of navigation

  • alter the behavior of the rewind button so that it also repositions the score, unless you have turned off the "Pan score automatically" button, in which case it doesn't. That is, make it work just like other commands that either do or don't reposition the score depending on the status of this button.

Reply

• Jul 31, 2018 - 18:37

I filed a formal feature request and submitted a PR to implement it - see #274841: Rewind should reposition score.

FWIW, the key to this for me is the change I made recently to the behavior of the "Pan score" button, which previously only affected behavior during playback. Now it affects behavior of all commands. That is, whether doing copy/paste or in note input or whatever, disabling that button prevents the score from repositioning. So now that there is a way to prevent the score from repositioning for those cases where that's what you want, there is no more argument to be made that the rewind command shouldn't default to repositioning just because "sometimes" you might not want it.

Reply

• Jul 31, 2018 - 19:08

Good observation, I hadn't thought about that - but when I investigated it, I found that technically, this isn't quite right.

First, the rewind command does not actually go back to the loop start point - it always goes back to the beginning of the score. To convince yourself of this, define a loop, start playback, stop it, hit rewind, then turn the loop off, and start playback again. You'll see it actually starts at the beginning, because that's what rewind did. It just wasn't obvious unless you turn the loop off after rewinding, because as soon as you start playback, the current position gets ignored and it always goes back to the loop start place. That in itself kind of surprises me sometimes, but I don't use this feature much, so if others like it, so be it.

Second, if you hit rewind during playback, rewind will also jump back momentarily to the beginning of the score (you can see the cursor flash there) but then will immediately jump to the loop start.

We could presumably alter the behavior of rewind with respect to loops, but that's kind of a separate thing. For now, since rewind really does go to beginning of score always, that's what my PR does as well. If after that playback happens to jump to the loop start, well, so will the score display.

Reply

• Jul 31, 2018 - 19:24

I think you're trying to put a square peg in a round hole to force an easy fix. If you define a loop, turn off the loop and press rewind then turn the loop back on, when you press play, it starts at the loop. There may be an instantaneous jump to the beginning then to the start of the loop when it's playing. Since I don't know the code I'm not sure why it does that, but seems more of a bug or a design decision to make it easier to program. If you define a loop, pressing the rewind key ultimately moves the play point to the beginning of the loop. If you turn off the loop button, by definition the loop is no longer defined, so in that case the rewind button will and should return the score to the beginning. Pressing the rewind button should pan the score to where the play button will start.

Reply

• Jul 31, 2018 - 20:55

I think you misunderstood slightly. I said to press rewind before turning loop off. So at the moment you hit rewind, loop is on. Currently, this does go back to the beginning, but you have to turn loop off afterwards and leave it off in order to see this.

The point here is, my PR doesn't change the actual behavior of rewind with respect to playback one bit. So if someone actually likes / takes advantages of / depends on that behavior, they will be happy. Rewind will continue to affect the playback cursor exactly as it always has. The only thing my PR changes is that rewind will also reposition the score.

Now, it may be that the behavior of rewind with respect to playback could stand to be improved - as you say, maybe it would be better if rewind went back to the loop start rather than to the start of the score. Or maybe not - maybe it's good to have a toolbar button that always goes to the start. As someone who doesn't use these features much at all (the loop button and the rewind are both pressed maybe twice a year for me) I don't feel qualified to make that call. But anyhow to me that's a separate issue. Whoever decides to tackle that issue, it would then be up to them to make sure the repositioning tracks the same way. But at least my code will be there for them to use.

I can make it easier for them by tweaking my code to make sure it literally tracks the same measure as playback, and add a comment referencing this.

Reply

• Aug 1, 2018 - 00:03

I suspect I got wordy and lost my main point. If the loop is turned on, rewind should always go to the start of the loop. If it's turned off, rewind should go to the start of the score. If you change the status of the loop afterward, the pan button will set the display correctly if pressed when you press play.

Reply

• Jul 31, 2018 - 16:01

I really do understand that the two buttons do different things and it varies according to whether MuseScore is in play mode or not. It's just not what I want as a user and, it's frustrating because I want to press a button which shows me the start of the score and resets the play pointer.

I'd be perfectly happy if this was a new key function CTRL+LEFT-ARROW or some combination that I could do with one hand. This would make it easier to play with an instrument without needing to use a mouse or mouse and keyboard (a pain when you're holding an instrument in your other hand).

Reply

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