#1774 Disabling Scroll to Follow Playback (pause) behaves oddly

[musewhirl]

Trivial, but confusing bug. During play, the window does not follow the playback when it goes off window, and that part is fine. But on hitting pause, it sometimes moves to the playback which was off screen, and at other times it does not. I cannot find the pattern to cause both behaviors on demand though. I also don't know whether the pause in the title of the button is supposed to be the same as hitting Enter, where the latter might easily be considered either a stop or pause. Anyway, I repeated the steps using the Transport Window to ensure that the pause concept was in effect by using its Play/Pause button.

Steps to reproduce:

1. Disable Scroll to Follow Playback (pause)
2. Open the Transport Window
3. Press play on the Transport Window
4. Wait for the playback to go well off screen
5. Hit pause on the Transport Window (same button)
6. The screen immediately moves to the playback, when I thought it would not follow the playback on pause
7. But this does not always happen, so try hitting play and let the playback go off screen again
8. Repeat a few times, and in my case, on pause, the screen does not move to the playback, sometimes for a number of times in a row

The main fix for this bug is to remove the inconsistency. Also note that I got that behavior without using the Transport Window at all. Scroll to follow was disabled by accident and on pressing Enter to stop play, there was the move to the playback off screen. Some time later, I got the other behavior where there was no move to the playback, and I was using the Enter button all the time for play and pause.

[Philip Leishman]

According to the code at the moment it seems that jumping to the cursor on stop is what should happen even if "follow playback" is deactivated.
I believe this sometimes doesn't happen because of a race condition between the gui and the sequencer threads.
So the first question to clarify is:
Should the view jump to the cursor on stop if "follow playback" is deactivated ?

[musewhirl]

I'm not sure what the answer is, but the tool-tip should match i.e. it currently mentions pause which seems to imply that when enabled the function affects pause. When enabled, there is no problem...since the cursor was being followed anyway and pause will not change the view anyway. So, this boils down when "Scroll to Follow" is disabled. In that case, perhaps the view should not move on pause similar to not moving while playing. That way the tool-tip wording is correct. If the decision is to adhere to the code and move on pause, then simply remove the pause and its parentheses from the tool-tip.

In my opinion, if someone had cause to disable the follow, it probably means they want to look at some portion of the timeline view while the composition plays, and presumably will be looking at that point when they decide to pause (stop). So, I'd go with not moving on pause when "Scroll to Follow" is disabled and leaving the tool-tip wording as it is.

[Philip Leishman]

The "pause" in the tooltip is the keyboard shortcut - pause key. Nothing to do with playback pause !
I agree with the second paragraph above - I would tend to say the track editor should not jump to the playback position on stop.
Any other opinions ?

[Ted Felix]

I also agree. If the user asks for no follow, there should be no follow. They should be able to get the view to jump to the cursor by simply enabling follow. Note that we currently do not do that, so that would need to be added. So...

1. Turning off "scroll to follow" should prevent transport pause and stop from jumping.
2. Turning on "scroll to follow" should immediately jump to where the playback position pointer is.

Does this sound reasonable?

[Philip Leishman]

Yes agreed.
See merge request.

[Ted Felix]

Philip's fix pushed as [bbc0a4]. Please test latest git.

[musewhirl]

In [91a1a7] PageUp/PageDown & Home/End no longer follow to scroll, when they used to. It feels like the problem would have been introduced very recently and this bug is probably when, although I didn't verify.

Steps to reproduce:

1. Ensure Follow to Scroll is enabled
2. Ensure the composition start is off screen
3. Place Playback Position Pointer in view
4. Hit Home and the PPP disappears of screen (presumably Home), but the view does not follow
5. Same for all the navigation keys: Home, End, PageUp and PageDown
6. Now disable Scroll to follow, and as expected nothing happens
7. But on enabling it, the view moves to Home (or to the PPP)

However, the bug still persists if repeated.

[Ted Felix]

It's the [254f98] fix that changed that.

Need to fix this so that PPP movements with the keys cause a scroll. Seems like it should do that in all cases, even with scroll-to-follow off. But just with scroll-to-follow on should be ok.

[musewhirl]

I should mention that even before the change, if the PPP was at the start of the composition and the start was not in view, then hitting Home did not change the view i.e. follow to Home. That's because the PPP was already there, even though I could not see it. In that case, I've always used an extra PageDown/PageUp combo to move to the start without having to reach for the mouse and scroll. I never bothered to mention it as a problem, but thought you should know since that is how it was originally.

I'm uncertain about what should happen with scroll to follow disabled since I've only ever disabled it by accident. But if the user had disabled it, they might hit Home while the composition plays, which would cause the PPP to move Home and continue from there. And they probably still don't want the view to change, since they disabled scroll to follow. Same for PageUp/PageDown, where they could count the number of times to move the PPP that many measures and hear where the composition was, yet be staring at whatever interested them in the view that was not changing. But for scroll to follow, then yes, it should behave as before i.e. change view if necessary for those keys.

[musewhirl]

Since I'm not actually upgrading to an official Rosegarden release for this test, I have some questions about the "old elements being deprecated" dialog which popped up when I built [90742d]. It seems innocent enough but it does want me to overwrite my autobuild (default studio) that I've had a long time. I immediately aborted in order to get some clarification. I'm sure appropriate documentation will surface when this hits the official release...or let me know if that documentation is somewhere already. Note, this is the first time I've seen a hint of incompatibility with previous versions of RG.

1. What happens if the user does not save i.e. they are using archived (completed) sessions with no intention of editing them in the future? Fortunately, the message does not appear on opening the session, only when trying to close it or open another. But this message will appear every time for every such session?
2. Let's say they continue until the inevitable deprecation day comes...is there a chance they won't even be able to open the session in order to carry out step (1)? I assume they could always go back to a previous RG version, load there and save (as requested), then continue with the version where deprecation occurred?
3. Being on master, let's say I save. Then some bug turns up which forces me to return to a previous master...that is rare, but not without precedent. Will the old master, basically a previous version, still open that session which was saved? This will apply to an official version too, where for some reason they realize they have to go back to a previous version of RG, but only after some time has passed.
4. Is there anyway for me to verify that I don't depend on those elements...seeing as I don't even know what they are? Bugs are tenacious critters, and if something were overlooked, then I could lose functionality until the issue was resolved, with no guarantee of getting the lost functionality back once fixed...not without losing changes made in the mean time...and I might not notice what was lost for some time in order to report it.

Anyway, you get the gist from the few questions, and I'm sure I won't be the only one wondering.

[musewhirl]

The previous post was supposed to be for Bug #1777 (not this one). That was the one I was going to test before I found the other changes on master. I have no idea how to fix a misplaced post though.

[Ted Felix]

the "old elements being deprecated" dialog which popped up

That's my fault and completely harmless. Just load/resave any files that trigger it and you are good.

It's related to forward compatibility and the matrix <velocity> tag. This stores the last used velocity in the matrix for each segment.

I had no idea that older versions of rg would abort loading a file if they found a velocity tag in an unexpected location. So I switched to using a velocity attribute instead. Still, the "old elements" dialog is triggered with files that were saved between a couple of recent commits. Loading and resaving gets rid of the "offensive" velocity tags and switches to using the matrix tag attribute instead.

Here's the story:

• [7e3ecf] - Seemed like a harmless change to allow the matrix to remember its velocity setting. But this introduced the velocity tag within the matrix tag which causes old versions of rg to abort loading those files.
• [be6c15] - Fix for the forward compatibility problem. Switch from tag to attribute.
• [bbbcf9] - Fix for failure to load files saved between the above two commits. Stop aborting when an unexpected velocity tag is encountered. The "old elements" message is still issued. Annoying, but harmless. Just load/save when you encounter it.

It's a small mess, but since we are between official releases, it is an expected hiccup. Those who jump from 25.12 to 26.06 should notice nothing at all.

I have no idea how to fix a misplaced post though.

Copy/paste, or link it from the other. That's about all that can be done in this issue system.

[musewhirl]

Ahh...so it rectifies itself for the sessions used in the code change window. That's great. So, nothing to worry about, and I can pull master in to test this bug and the others I have outstanding.

I'll leave the misplaced paste here since sessions used for testing this bug may be affected anyway. It was just that at the time of the post I was updating to test bug #1777 and that's when I saw the popup. I'll be testing this bug shortly.

[Ted Felix]

Just pushed a fix for the Home/End/PgUp/PgDn keys not following: [82561e], Please test latest git.