Proposal Smoother Playback Scrolling

The Problems
These problems occur only when "Update display while playing" is checked in Tracks Preferences:
 * If you drag the scrollbar in either direction while playing, the timeline moves subliminally but then jumps back with the playback cursor positioned at the left edge of the waveform display.
 * If you scroll right while playing, when the playback cursor bumps the left edge of the track waveform display the ruler can get out of sync with the waveform. Playback then corresponds to the time indicated in the ruler, not the position of the cursor in the waveform (this is reported on Mac). On the other platforms, flickering waveform corruption can occur. On Windows, task switching to another app and back while holding either button on the Audacity horizontal scrollbar causes Track Panel corruption.
 * Adding a label when playing then leaving it open is not a good experience if the label goes behind the scroll.
 * On Windows, holding CTRL (as you might as preparation to add another label at an exact playback position) jumps rapidly between label and playback position until you release. On Linux, holding CTRL only moves once to label then back to playback position.
 * When you quickly hold CTRL + M and type, the Timeline will jump back to the old label while it closes, then move the Timeline to a new position with the old label centered in the waveform or the new label at the left edge of the waveform.
 * Display update while playing could be described as "klunky". The waveform display jumps every time the playback cursor reaches the right edge of the waveform display. This is currently a Feature Request:
 * Smoother Track scrolling on Playback: Keep the cursor in one place but move the track - gives smooth visual playback without continual cursor back and forth (14 votes)
 * As selectable option which is on by default in case of slower systems.
 * Or still allow cursor to move, but scroll smoothly when it reaches about 15% from the right and place cursor 15% from left (1 votes).

Developer / QA Backing

 * James
 * Bill
 * Gale

Bug References

 * Bug 105

GSoc Ideas

 * Oscilloscope mode

Need for Update Display Preference
Gale: Ideally I would like a solution that allows us to do away with the "Update Display" Preference. Are auto update while playing and being able to scroll while playing really incompatible? Would anyone not want to update, except for processor speed reasons?

Playback cursor de-synchronization
On Mac the following behaviour is observed:
 * 1) New Project
 * 2) Generate chirp amplitude 0 - 1 (so it's easy to see), any length but lets say 30 seconds
 * 3) New track, generate another chirp
 * 4) Drag chirp from second track onto first, delete first track - you now have two chirps each in its own clip with a clear boundary between them - the effect is not dependent on having two clips: you can join them if you want
 * 5) Skip to Start then zoom in so you can only see the first chirp
 * 6) Click Play and wait a few seconds
 * 7) Click and hold the right scroll button - eventually the playback cursor will bump against the left edge of the waveform display area
 * 8) Continue to hold the right scroll button for a second or two - note that the boundary between the two clips is no longer at the 30-second mark - playback corresponds to the timeline, not the waveform display - on the Mac tested, the boundary moves to approximately 29.5 seconds and stays there
 * 9) Click Stop - the waveform jumps back to where it is supposed to be.

On Windows: LL reports: This happens on Windows too, but with a slightly different visual effect at step 8. On Windows, you see the end of the first clip alternate between the 30 second mark about 29.5 or so.

On Windows and Linux: Gale reports: Actually I don't get desynchronisation on Win XP or Linux that I would call such. The end of the first chirp is rapidly flicking back and forth between about 30s and 29.5s. That corruption stops near the end of the second chirp when the playback cursor is able to travel freely past the left edge of the waveform as it approaches the end of the track.

Smoother Scrolling
Bill prefers the first option listed above - keep the cursor in the middle of the track display. This nicely simulates tape moving past a playback head (for those of us who remember such things). Gale agrees, but also wants to keep in mind in our solution the significant issues we have with scrolling/zooming not preserving the audio context (bug 15).

Handling open labels during playback / recording
Gale 25Apr11: When the track is static, it's good that typing an input character or SHIFT and input character moves focus back to the label. It's not so good that SHIFT, ALT and CTRL on their own also do this. When playing/recording, what should happen? If an open label has gone behind the scroll then receives legitimate fresh input (not CTRL or other irrelevant input), maybe it should take and keep focus until closed, then focus returns to playback/recording cursor? Timers to control this may not be a good idea when playing/recording.