1) When the program detects this, insert zeroes into the recording to keep the
other good parts synchronized.
2) When recording stops, a message box alerts the user, and a label track is
added showing the lost parts, labelled with consecutive numbers.
3) A menu item visible in alpha builds only is added to Tools, to simulate
recording errors at random times and test the reporting feature.
... If you record or append-record, and do things during it that affect
the undo stack, and then complete recording -- then the last undo item will
undo the recording completely, and the other changes will belong to earlier
undo items that contain no part of the new recording.
Things that affect the undo stack during recording can include new undo items
such as movement of pan and gain sliders or adding and editing of labels
with Ctrl+M or Command+.
But such things also include certain changes of view that do not create new
undo items but rather update the most recent undo item to include that change.
Examples are change of mute or solo, resizing of tracks, changes of selection,
zooming (horizontally or vertically), switch among wave track view types, etc.
Fixing this was a rather involved project. This ought to be tested
thoroughly to be sure there are no other odd surprises in the behavior of
undo.
... in case you also do things, concurrent with the recording, that affect the
undo stack, either by pushing it (such as by changing the gain on one of the
playing tracks, or making a label) or by "Modifying state" without a new undo
item (such as when you change its size or mute or solo).
... But perhaps we are developing the means to relax even this ban safely.
For instance, why not undo a mistaken AddLabelPlaying command (Ctrl+M) without
stopping the recording?
... Being careful not to use operator == on a default-constructed
std::list::iterator, which violates assertions in the MSVC libraries.
This reverts commit 7fb5ec4b7ab4f9302bd94446db86924cd2b8d67f.
... and require qualified name access to use the underlying std::list iterators
that return shared_ptr to Track.
Which should not be done very much outside of class TrackList, but a few
places need it.
- Added new facility whereby parameters can be optional, and can be
tested for their presence.
- Can now set Pan, Gain, Selected, Solo, Mute, Focused using SetTrackInfo,
mirroring what GetTrackInfo can do.
... Maybe a good feature idea, but the implementation pollutes the code in
too many places.
It's a special case of the more general idea of many-to-one associations
between screen rectangles and track objects. More generalized ways to
accommodate that should be sought.
... This even makes it possible to remove the prohibition of undo and redo
during transport, not that we want to though. Playback and recording will
continue, using track objects that might not be in the current project.
Repair work involves lots of zooming in and out, to use the repair effect on up to 128 samples.
Ctrl Mouse-Wheel zooming now will zoom to ends of selection, if available, or mouse position otherwise.
Zoom-Toggle hyphen removed and Preset2 changed.
Button tooltips tweaked to match menu entries.
This is an update to commit 516af71. The Dock key is now retained in the config file, so that if a user goes back to a version before the fix, the toolbar layout remains unchanged.
Note that when ToolManager::ReadConfig() is called, InitPreferences has already been called which has set the version keys to the current version of Audacity. Therefore the initial values of these keys are stored in AudacityApp.
Problem (at least on Windows 10): The commands no longer work properly. For a simple example, with one track selected, and the last clip selected, next clip moves to a non existant clip.
This was caused be commit baec816. In this commit, a member function was added to the struct FoundClip. Because FoundClip is no longer POD, statements such as:
AudacityProject::FoundClip result{}; no longer zero initialize the struct.
Fix: explicitly zero initialize the data members of FoundClip. I've also zero initialized the data members of FoundClipBoundary, where their are potentially similar problems, although there were no problems in my tests.
