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.
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.
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.
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.
This also now shows a new green 'play cursor' when ctrl is held down on wave track, and shift being held down is signalled by a cursor change to finger-pointer too.
I also accidentally enabled EXPERIMENTAL_MIDI_OUT. We may disable that in December for release. Leaving it in for now.
ESC Key toggles snapping of center frequency to peaks (no visual indication of snap to yet)
Description added to mouse prefs - fix later.
Shift now required to keep top/bottom frequency pinned whilst (re)dragging the other one.
Code for status bar messages simplified and made more consistent, and no longer hard codes assumption that preferences is Ctrl-P when prompting user about it.
This relies on three new nyquist scripts to actually do the editing. The peak-snapping code in FrequencyWindow has been extracted into a new class, SpectrumAnalyst, to provide peak-snapping in spectrogram too.
This change is believed to be a direct refactoring that does not change functionality. It paves the way for more complex kinds of selection, such as selections involving frequency as well as time. It also reduces risk of left and right edges being swapped in future code using SelectedRegion, as the default is to swap on assignment if needed.
Completes James' TimeConverter work
This completes the work that James started. It moves most of the non-GUI
related processing from TimeTextCtrl to James' TimeConverter class.
Other changes include:
1) TimeTextCtrl now expects the format name instead of the format string to be
passed when creating a new instance. I found that almost all cases created the
instance with a blank format string and then set the string after creation.
2) To simplify maintenance and prevent a possible discrepancy between the two,
Increase() and Decrease() were merged into a single routine.
As a result:
1) All cases where a TimeTextCtrl was being used to extract information and
not actually display a control have been changed to use TimeConverter instead.
2) All cases where TimeTextCtrl was being created with an empty format and
then immediately followed by something like this:
tt.SetFormatString(tt.GetBuiltinFormat(c->GetFormat()))
have been changed to pass the format name instead of the format string when
creating the TimeTextCtrl instance.
This is part 1...
Provides some relief to the selection "hang"
This patch adds the ability for the keyboard based commands (like cursor left,
extend selection right, etc.) to know when the key has been released.
When the patch is applied the current state is saved only when the key is
released and not every time it repeats.
Here's an example of the difference it makes.
This video show the selection "hang", but also watch the CPU usage. All I'm
doing is pressing SHIFT+RIGHT ARROW.
http://youtu.be/tdMntDwGSkM
This one is the same thing bug with the patch applied. Notice that the
selection "hang" no longer occurs and look at the CPU usage!
http://youtu.be/EpXNsQ4Cky0
Undoes Roger's fixes for bug 255/148, as this was one component of the bug.
This fix restores TrackPanel::RefreshTrack to using a cliprect instead of doing an entire refresh.
It does it by using a repair flag in TrackPanel::DoDrawIndicator that does not advance the indicator time (so the only place the time can advance is in OnTimer)
I tested to make sure both bugs were okay after my fix.
This fix may restore usability enough to resolve the bug, but I note that there are other potential optimizations we can make, discussed on the bug 406 bugzilla comments.
Further shrink minimize button width and center the button in the TrackInfo, so there's a blank to left and blank-or-sync-lock-icon to right, so track can be selected easily even when minimized.
(TrackInfo::DrawBordersWithin) Instead of gray line spanning TrackInfo at top of minimize button, draw it just the width of the button, and add one to the left of the minimize button.
Separate sync-lock icon drawing from minimize button drawing.
Make some magic numbers become named constants.
Some renames for clarity. Clean up some unused stuff.
