Transport bar: Rewind to start position should be represented immediately on screen
If you press the "Rewind to start position"-button, nothing seems to happen. After pressing "play" again, the view plays from start. That is a pretty small bug, but I think that is just annoying...The screen view should represent the position of the "tapehead" at least after a tapeheadJump.
I work with WIN 8.1, MS 2.02. This behaviour is independent from a special case or file, so no file is attached.
Comments
This is not a bug. Rewind is specifically about playback - it has nothing to do with screen display. To reposition the screen display, you use the Home button, just as with any other program like a word processor that doesn't have playback.
In reply to This is not a bug. Rewind is by Marc Sabatella
hmmm, can't agree 100%, but since I brought the word processor functionality in another thread last week as an argument to you, (copying single notes (and sequences) out of a chord), I cannot say that it was unimportant to have a homogenious GUI software behaviour landscape today.
But there are also moments sometimes, I wish, the MS view was less coupled with the playback. Try to move the view while playing back...that is imho impossible. Is it coupled, is it seperated, or is the playback behaviour propably not considered in the minutest detail at all?
The ONLY case, i can imagine, where the screen should not represent the playback is, when I want to check visually several bars on eg. part C by listening on part A for analysis of my work...this is not possible. I think, a scorewriter software should be much more influenced by DAWs or video cutting software sometimes, because music (as the final product) in itself is a time critical, linear task, but editing it is more an iterative one. In some DAWs you can find a dedicated coupling/decoupling button (view / playback) or it works that way, that view synchronizes to playback by default, but the user can break coupling at any time by just using some view-concerning functions of that software. That works great to my mind.
From an ergonomical pov, the decoupling of playback and view in only the wrong half of the comfort zone does not make much sense.
OK, I could agree at maximum 30%, that is for sure now, after reading my written lines myself
In reply to hmmm, can't agree 100%, but by olivo
"Try to move the view while playing back...that is imho impossible."
There is actually a button in the toolbar that lets you choose whether the score moves with the playback or not.
I would suggest that your proposal (which others have brought up before) would make sense if things behaved that way when "Pan score during playback" was turned on, and the current way (i.e., nothing) if turned off.
In reply to "Try to move the view while by Isaac Weiss
"There is actually a button in the toolbar that..."
Thank you for that.
I never saw that button before.
I also would support your proposal to have the "switched" behaviour
In reply to hmmm, can't agree 100%, but by olivo
FWIW, I don't necessarily believe the current behavior is the best possible design for all situations; I was just pointing out it *is* by design and not a bug. But designs can of course be changed.
I'd also observe that playback position and view position are not in sync *most* of the time. Any time you move the score, the play position stays where it was, and that is normally considered a good thing. Although it is possible that expectations depend in part on whether you on any given day you are mostly listening to playback with only minor amounts editing, or mostly doing editing.