Problem: up to about 300ms was intermittently truncated from the end of recording.
The bug was introduced by commit a0256e9.
The fix: in this commit, the line:
the line:
mRecordingSchedule = {}; // free arrays
was added to the lambda in the definition of cleanup at the start of AudioIO::StopStream()
If this line is changed to:
mRecordingSchedule.mCrossfadeData.clear(); // free arrays
then this has been found to fix the bug, and the vector is still cleared.
Clearly, the reinitialization of one or more of the other data members of mRecordingSchedule was causing the bug.
Which of the these reinitializations are the problem, and why is not known, and due to the nature of the problem could well take some time to find out.
Some former 'On' functions have been renamed 'Do' since they didn't directly handle the menu item. Some functions that used 'Context' now use 'Project'.
... This forces a better placement of state variables in the appropriate
classes.
In future perhaps, MenuManager should be splintered into several classes, one
for each of the main toolbar menus.
Flipped some conditions and used if else-if to reduce the indentation in code.
This makes the code more readable. No change in functionality.
Also created UpdateTimePositions() and made some bool functions void.
new variable mMaxFramesOutput used to communicate positional change.
... This string appears when you enter a positive, invalid value for peak
amplitude in the Normalize effect. It didn't look right with periods (a space
was left before the first period). Let's use parentheses instead.
AudioIO.cpp has nearly 6000 lines and needs to be broken up into separate aspects.
The main point of the new split is to better separate the time critical callback code (that runs in the portaudio thread) from the code that interacts with the disk (that runs in the Audio Thread).
Menus.cpp is over 10,000 lines. The main point of the split is to make possible a new .cpp file for MenuCreator, which is responsible for the creation of the menu bar, and which contains the near 2,000 line function MenuCreator::CreateMenusAndCommands()
The menu handlers are also (better) separated from the menu management.
We ask 17 times for different rates, and for some drivers that is too much of a flood.
Workaround is to use a small delay between requests.
Only happens at start up, so is acceptable to just always do it.
The for loop was only to test if *some* track was selected, and its body only needs to be executed once.
Note that an empty IteratorRange is false and one with something in it is true.
Tidy translation code in init.lsp
Include rms.ny in Makefile.am
Add rms.ny to Linux package
Update Makefiles with: autoreconf --force --no-recursive
Add rms.ny to mac build
Add rms.ny to Windows build
... so that std::reverse_iterator<TrackIter<T>> works right, not making a
subtle error of return of reference to a temporary in its operator * with some
compilers.
... This might be the reason for Linux crashes when playing-at-speed.
This was a bad thing to do with any compiler -- not to be blamed on
possible compiler bugs.
There was a warning about this in the XCode build.
Problem: profiled the limiter effect, and found that wxGetLocalTimeMillis() in ProgressDilaog::Update was taking up a lot of time.
The slow down of the nyquist effects and analysers was introduced by the switch to wxWidgets 3.1.1, so presumably there was some change to the implementation of wxGetLocalTimeMillis()
Fix: Use wxGetUTCTimeMillis() instead of wxLocalTimeMillis() in ProgressDialog.cpp. This is much faster on Windows, and wxWidgets recommend its use to due wxGetLocalTimeMillis() being affected by start/end summer time (daylight saving time).
... The crash happened in drawing code. The recently submitted but long
developed rewriting of track and channel iterations wasn't all reconciled
with the early 2.3.0 development relating to temporary track objects for
display purposes, which was for fixing the interactions of recording and undo.
