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.
