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.
A very extensive rewrite.
No longer:
1 Test a type field of a track and then do a C-style pointer down-cast
2 Use verbose old iterators over tracks that required those down-casts
3 Detect that a track has a stereo partner by testing Track::GetLink();
Detect that a track is the left stereo channel by testing Track::GetLinked()
4 Do something to one channel of a pair, then repeat on the other channel
5 Set up new or imported stereo tracks with Track::SetLinked() and setting of
channel types
Instead:
1 -- Use track_cast, which won't cast const away, to convert a pointer, getting
null if the track is not of the specified type
-- Or use Track::TypeSwitch which takes lambda expressions with arguments of
desired subtypes, entering the lambda body only if the track has the
right type
-- Or use TrackIterRange<...>::Visit() or VisitWhile() to apply a
type-switch over each of several tracks.
2 -- Use TrackList::Any() or Selected() or other new functions, which return
TrackIterRange<...> objects that represent ranges of tracks to be visited.
-- Use the template type parameter to restrict visitation to a subtype and
cause the pointer down-cast to be built in to the iterator deferences.
-- Use C++11 range-for or stl algorithms with TrackIterRanges for brevity
-- Or even avoid loops by using size() or min() or similar member functions
of TrackIterRange.
-- Use StartingWith(), EndingAfter(), Excluding(), and operators + and -
(which can take arbitrary predicates on tracks) to filter the range object
and simplify loop bodies even further.
3 -- Use Track::IsLeader() to test whether a track is first in a channel group
(which also returns true when it is not grouped with any other track, and
maybe not even a WaveTrack)
-- Or use TrackList::FindLeader() to get the first member of its group
-- Or use TrackList::Leaders() to get a track range that includes leaders
only, then visit that range as in (2).
4 -- Use TrackList::Channels() to get a TrackIterRange that includes only
the members of the group of a given track and visit that as in (2).
-- Do not needlessly assume or assert that the channels are at most two.
5 -- After all the channels have been added at the end of the TrackList, just
call TrackList::GroupChannels() passing the leader track and number of
channels.
Most rewrites covered by (3) and (4) generalize without any complications to
possible future more-than-stereo track groupings. In other places, there may
be some difficulty about such generalization, and those are marked with the
comments:
// TODO: more-than-two-channels
or else
// TODO: more-than-two-channels-message
where it was merely a matter of more appropriate wording for the user. This
branch makes no changes to user-visible messages.
What isn't changed in the interface exposed by TrackList and Track:
-- Grouped channels are always a contiguous sub-range of all tracks, and
client code may rely on that assumption.
What isn't changed in the implementaion:
-- Channel groups are never yet actually more than two.
-- The grouping of channels is still represented by a boolean flag in each
track that is true only for the first channel of each stereo pair.
-- The persistent representation of channel groups in .aup files.
... except that WaveTrack needs to be a friend, just for reloading from disk.
Nothing yet is changed in the internal or persistent representation of channel
groups.
