... Intermittent crash, depending on some accidents of memory page allocations,
known to happen sometimes when playing a 44100 Hz track at 32000 Hz; the
strange story is in the code comments
... So that if you save, edit, compact, close without saving, then reopen,
you recover the saved state as expected, not the compacted state.
Implications:
Do not push an undo state for compaction. Discard redo states instead.
Do not purge undo states after the last saved. The database still needs them.
So we might reclaim less space than before.
* Exit the update_po_files.sh in case of errors
* Let users update audacity.pot only
This can be done by calling
AUDACITY_ONLY_POT=y ./update_po_files.sh
... The setting of scale type now happens in the default constructor of
WaveformSettings, which calls LoadPrefs.
Since creation of WaveformSettings is always forced, we don't need the
distinction between WaveTrack::GetWaveformSettings and
WaveTrack::GetIndependentWaveformSettings.
That distinction was more analogy with the handling of SpectrogramSettings that
we don't need now.
... Never written, because WaveformPrefs is never constructed and added to
the Preferences dialog.
It's still an old unrealized experiment, to make a Waveform preferences page
analogous to Spectrogram preferences. Until such time as it happens, don't
complicate the fix of bug 2480 at commit 238bb95.
... This is a vestige of the time when "Waveform" and "Waveform dB" were
considered separate wave track view types. But now that scale choice is
independent of Waveform vs. Spectrogram choice, there is no possible change of
scale type happening here, requiring invalidation of the vertical ruler.
... Problem began at commit 238bb95 and is fixed by supplying correct default
values to gPrefs->Read(...)
The bug was introduced only for Spectrogram settings, not for Waveform.
The clip left/right commands can now time shift clips, notetracks, and labels.
So:
1. Rename them Time Shift Left/Right
2. Move them the to edit sub menu of the extra menu, which is more appropriate than the Cursor sub menu.
Problem:
In DoClipMove() in ClipMenus.cpp, there are a couple of problems in the code for the adjustment of the new value t0 due to potential rounding errors:
1. The code uses the start and end of intervals, and these values are not updated after the move.
2. It's assumed that the same correction is valid for all track types.
Fix:
Implement an adjustment which depends on track type, and does not use the start and end values of intervals.
