Audacity Forum

I discovered a minor bug that appears in recent versions. I didnt see such bug in older versions.

Let's say I have a 1 minute track and I have zoomed into track so that the visible part of the track is less than 1 minute - let's say only 10 second is visible within scrollpane for now. Assume that I have used the selection tool to click at somewhere in middle of track, say at the 3 second mark.

Now when I press spacebar to play from the 3 second mark. The playback line moves to the right and when it reaches beyond the visible part of the wave, the scrollbar scrolls itself to catch up the playback line. Now, after the wave scrollpane has scrolled, let's say I press spacebar to stop the playback. Up until this point, there is no problem.

If I now press spacebar to start playing again from the selection(3 second mark), the scrollbar SHOULD rewind itself so that the selection is exactly on the leftmost of the visible part before it starts to play. This is how the older versions behave.
But now with the newer versions, I see that when I press spacebar to start playing again from the selection(3 second mark), the scrollbar scrolls itself to an odd place. In a fraction of a second, the scrollbar shows where the selection is. After that fraction of second, the scrollbar already jumped to the next viewing position to catch up the playback line.

This annoying scrollbar jump is basically avoidable if the scrollbar has initially moved to the right place and shows the selection aligning to the leftmost of view.

sccy wrote: ↑

Thu Apr 11, 2019 11:45 pm

But now with the newer versions, I see that when I press spacebar to start playing again from the selection(3 second mark), the scrollbar scrolls itself to an odd place.

On my machine it looks like the track is being scrolled back to align the start position (the 3 second mark) with the left edge of the track info panel (the extreme left end of the track) instead of the the right edge of the info panel (the left edge of the waveform display area of the track). Is that what you see?

I think this behaviour is wrong (it should scroll to the start of the waveform region of the track), but Audacity has been like this for a long time (at least version 2.1.2 if not earlier).

Sorry. Don't know if I have fully understood you, but I guess you have got the idea of what I was trying to say.

Please see my screen dumps in the attachments.

I have a more than 3 minute track imported. I select somewhere on the track, say 46.5 sec. I start the playback and let the info panel scrolled to the right. I stop the playback at around 50sec. I press play again and I see the info panel jumps back. However the info panel was first scrolled with the right side of panel aligned to the selection. In a fraction of second, you can see the playback-cursor moved to the left side, and then the info panel scrolls/jumps again to catch up. It looks like a glitch... although the audio does play smooth and fine at this point. After that scrolling "double-jumps" within a fraction of second, the info panel and playback-cursor find the correct position. Info panel then continues scrolling normally.
May be this isn't really a technical bug for the development team. It may be seen as just an undesirable behaviour to users... but to me, it does affect my productivity a great deal. Recently, I have to work on some dialogue-oriented work, which involves syncing of many short clips. I have to zoomed in very close to a track and repeatedly playback a few seconds specifically forth and back many many times on a bad day. (Just to check - visually and audibly - if certain tracks are in-sync or not) Because of the repeated playback of short ranges of time (and scrolling of the info panel) so many many times, the aforementioned "double-jump" behaviour does really affect me visually. Straining my eyes literately.

To overcome such problem, I have to do the following for each playback.
Before each playback:
1. double tap the spacebar to relocate the scroll position,
2. manually mouse-scroll the info-panel a little to the left,
3. and then press spacebar again to play for real.
Sounds like a lot of work just to playback a short range repeatedly... but that's how I get to see the start of the range carefully each time I play it.

I would appreciate if the info panel jumps align to its left edge like how it was in older versions so that there is no more of these "double-jumps"... It's just a lot more intuitive to users this way.

I have logged the bug here: https://bugzilla.audacityteam.org/show_bug.cgi?id=2094
Does my description match what you are seeing?

I am getting this issue on Windows 10 x64 with Audacity 2.3.3. This is contrary to https://bugzilla.audacityteam.org/show_bug.cgi?id=2094 which claims this is a Mac/Linux bug.

Procedure

• Set the “play start point” somewhere in the middle of the audio file. (Not sure if necessary.)
• Scroll so the “play start point” is just barely off-screen, to the left or right of the viewport.
• Press Space to play, again to stop. Rinse and repeat.

Audacity's behavior

I think Audacity's behavior can be modeled as an event-drive state machine. Each of the following tasks will trigger a series of events.

Start playback with the "play start point" off-screen to the right

• [Start playback]
  • The “current playback” cursor starts from the “play start point” and moves to the right.
  • Some “initiate playback” UI lag occurs, then the UI becomes idle.
  • The viewport does not move yet.
• [UI idle, “current playback” cursor off-screen to the right]
  • Audacity scrolls the viewport rightwards so the “current playback” cursor is on the left of the screen, which takes time to redraw.

The behavior is fairly deterministic. The "play start" point is just barely off-screen (on the left), by a distance equal to the duration of ("initiate playback" UI lag).

Start playback with the "play start point" off-screen to the left

• [Start playback]
• Sometimes: [UI idle, “current playback” cursor off-screen to the left] (second event)
  • Audacity scrolls the viewport leftwards so the cursor is on the right of the screen, which takes time to redraw.
  • Afterwards, the play point has already moved off the screen (to the right). Trigger event [UI idle, “current playback” cursor off-screen to the right].

Why does the second event only happen sometimes? The "current playback" cursor starts from the "play start point" off-screen to the left, and moves to the right. If the "current playback" cursor goes on-screen before the UI lag ends, Audacity will not jitter. If the UI lag ends while the "current playback" cursor is still off-screen to the left], the second event will occur, and Audacity will scroll and redraw twice in succession.

If you (start playback with the "play start point" off-screen to the right), the viewport will move just past the cursor. If you then stop and play, there's around a 50% chance the second event will happen. If you move the viewport to the right so the "play start point" is far off-screen to the left, the second event is more likely to happen.

Once the second event happens, the "play start" point will be off-screen to the left by the same amount of time as the first redraw took (around 0.4 seconds in spectrogram mode, around 0.1 seconds in waveform mode). Since screen redrawing delay is longer than start-playback lag, every time you stop and play again, then the second event is pretty much guaranteed to recur.

Conclusions

I feel these behaviors are poorly thought out. I suggest changing how Audacity responds to certain events:

• [Start playback]
  • If you start playback with the “play start point” off-screen to the left or right, the “play start position” should scroll to the left of the viewport.
• [UI idle, “current playback” cursor off-screen to the left]
  • Unnecessary to change, but this could scroll the viewport leftwards so the cursor is on the left of the screen. But if users can scrub through the document towards the left (reverse playback), this is bad because it creates constant redraws.

As a result, initiating playback is no longer dependent on the whims of the "current playback" cursor, UI playback lag, and redraw lag.