... And it resumes if Audacity regains focus.
Actually this fix causes pausing and resuming depending on whether Track Panel
has focus, so clicks in other parts of the Audacity window may also pause the
scrubbing. I hope that is acceptable.
Also has this effect: Generate sound, scroll left, then delete the (sole)
track. Create new track from menu. Formerly, the track did not align 0
to left edge. Now it does.
This removes the TrackInfo's slider "cache".
Originally, the cache would build to the maximum number of tracks you
had created in an Audacity session. So, if you created 128 tracks
and then reduced that to 1, you'd still have 256 sliders, 1 gain and
1 pan per track.
But, the only real thing the cache did was prevent continuous allocations
of sliders since the allocated sliders position and values wer still
being updated nearly with ever interaction since they were redrawn each
time.
In April 2010, the slider cache was changed to reduce its size by
creating a sort of ring buffer based on how many tracks were displayed
and how many tracks were in the project (I guess). Unfortunately, it
didn't really handle large number of tracks and this bug was born.
While trying to find the proper fix for this, I realized that the
cache really wasn't saving anything. Maybe a little when dragging
the thumb, but during normal track redraws and interaction, it really
didn't serve a purpose, other than use additional memory.
So, I've removed the cache and have allocated a single gain and a
single pan slider. As before, their position and value are changed
as needed when drawn and manipulated.
When it is enabled, the project can scroll up to one-half of a screenful
beyond time zero or the maximum track time. I was careful to disable selection
of negative times.
This is motivated by the smooth scrolling scrub. It behaves more sensibly at
the extremes. It can still keep the play indicator centered.
Also removed an unused member of ViewInfo.
Bug 961 - Play cursor broken after double-click scrub play
Bug 962 - Scrubbing gesture during recording places Audacity in scrubbing mode
when recording stops
Bug 937 was a consequence of mouse capture for drag, which no longer happens.
Scrubbing starts with ctrl- (or cmd-) left- (double-) click, after which mouse
movement and shift key and scroll wheel (undepressed) govern scrubbing. No
buttons need be held. Another ctrl/cmd-left click can stop scrubbing, and so
can SPACE or Stop button or other commands that stop normal playback.
I've added code that now treats sample editing as another kind of mouse capturing activity (IsAdjustingSample). We will now not undo or redo whilst mouse is captured. Does not depend on what key binding is used for redo/undo.
EXPERIMENTAL_SCRUBBING_BASIC enables middle-click-drag to scrub, or to seek
when shift is down.
EXPERIMENTAL_SCRUBBING_SMOOTH_SCROLL adds middle-double-click-drag to
scrub or (with SHIFT down) to seek while keeping the playhead at the midline
of the track display.
EXPERIMENTAL_SCRUBBING_SCROLL_WHEEL allows control wheel to vary the speed
limit, while scrubbing (not seeking).
All three are enabled in this commit.
Also notice the changes to status bar messages and the Mouse Preferences dialog.
Scrubbing works only in Select and Multi tools.
In particular, use an options structure for AudioIO::StartStream to simplify
calls
ControlToolBar::PlayPlayRegion also takes that structure as an argument, and a
SelectedRegion instead of two times
And other changes
For now, let it abort vertical scale zoom
(any mouse button in any tool, in the vertical ruler)
and horizontal zoom
(any mouse button in the zoom tool or right mouse button in the multi tool,
in the wave display)
Should any other drags be escapable too?
Time shifting? That would need some more work to restore initial state.
Otherwise the following assertion gets triggered:
../src/common/wincmn.cpp(3271): assert "!wxMouseCapture::IsInCaptureStack(this)" failed in CaptureMouse(): Recapturing the mouse in the same window?
Based on the fix provided for an identical assertion triggered elsewhere,
described here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765779
A 4hr track used to take about 20s to cut a few samples. This is now significantly improved, to around 3s. Leland did this by
(a) moving the size calculation to when we examine the undo history, so it isn't slowing down the edits.
(b) in size calculation, using sizes that are cached rather than going to disk to find the sizes.
(c) writing the autosave file which is to an FFIle to a string first, i.e. using XMLStringWriter as a buffer for XMLFileWriter.
Step (c) may also make autosave marginally safer, as the risk of a partially updated autosave file is reduced.
This was my bad. I'd reset the number of capture channels
in AudioIO when the stream was stopped. Unfortunately, two
methods depended on it being valid AFTER the stream had
stopped.
Those methods, TrackPanel::OnTimer and AudacityProjecT::OnCloseWindow,
were using it as an indicator if recording had been taking place
before they stopped the stream. They then flushed the tracks, pushed
the state onto the undo stack and did some other post-recording tasks.
Turns out that the tracks are already flushed as part of the normal
AudioIO::StopStream processing, so that was redundant.
And, instead of duplicating the process, I've relocated most of each
methods processing to AudacityProject::OnAudioIOStopRecording.
When undoing not only should the capture state be checked to
see if it safe to undo, but the captured track should be
checked as well since some activities only set the captured
track and not the state.
The problem was that the mouse capture was not being reset
when the pointer left the track panel. In that case, as
long as no buttons are down, the capture state needs to be
reset so that when the mouse re-enters the track panel it
figures out what is going on from a clean slate.
These are mostly under an EXPERIMENTAL_ #ifdef. Also has a change for the prompt string for preferences so the displayed keybinding is adjusted when in multitool mode.
