These changes fix a broken build in Windows.
#include <algorithm> needed for min/max to be in std.
decltype(+name) was declaring a const variable, that could not be incremented. Changed to auto.
In particular, use an options structure for AudioIO::StartStream to simplify
calls
ControlToolBar::PlayPlayRegion also takes that structure as an argument, and a
SelectedRegion instead of two times
And other changes
The problem from the beginning has been that some parts of the code expected to
receive interleaved buffers from Dither and some expected non-interleaved buffers.
I was trying to keep the changes to a minimum, but it just wasn't possible.
The result is that Dither can now accept any combination of non-interleaved and
interleaved source and destination buffers.
I still want to review every single usage of Dither (and all of the intermediaries)
because I've seen allowances here and there for the lack of Dither returning
interleaved buffers. Since it can now return interleaved buffers, some of that
extra processing can be removed.
For Resample.* and QualityPrefs.cpp, this commit has my restructuring for distinguishing constant-rate vs variable-rate resamplers more generally. I think it's complete and ready for const-rate, but I have more review and testing to do for the var-rate cases.
Variable-rate resampling is not implemented here, so Time Tracks are still broken, but this is a milestone in getting to a more general and correct structure.
Also I think this fixes AboutDialog issues Steve noticed.
Update the implementation to make sense in a multi-clip environment.
Previously, a mix-and-rendered track always contained silence from time zero
until the time at which the first audio happened, as well as silence between
sections of rendered audio. Any audio before time zero was silently lost.
These changes mean that the single rendered clip now starts at the first sound in any of the tracks being mix-and-rendered and stops at the end of the last sound. This avoids a lot of unneccessary silence, and ensures that mix-and-rendering a single clip in a track leaves the clip the same length in the new, rendered, track. This is very useful.
These changes should also fix at least one bug in the case where a user-defined selection is being mix-and-rendered, although it is not currently possible to do this from the UI.
This saves a lot of typing if it is necessary to render a lot tracks in-place whilst preserving their names.
It is currently impossible to test that the two channels of stereo tracks get the correct name, as making stereo tracks always results in tracks with the same name for both channels ... This code would be much simpler if stereo tracks were objects.
This function (Mix and Render) could be made simpler if it used the TrackList functions like GetNumExportChannels() and made better use of conditional iterators rather than working it out for itself.
Was able to make the bug occur after lots of fast clicking around, by double-clicking Preview in Amplify dialog.
The key seems to be the call to wxYield. That function is obsolete, but looking at the documentation for its successor, wxApp::Yield():
"Caution should be exercised, however, since yielding may allow the user to perform actions which are not compatible with the current task. Disabling menu items or whole menus during processing can avoid unwanted reentrance of code: see ::wxSafeYield for a better function."
That sounds like exactly the situations where this has occurred. And the documentation for ::wxSafeYieldsays:
"This function is similar to wxYield, except that it disables the user input to all program windows before calling wxYield and re-enables it again afterwards."
Sounds like what we need. So I went through the code and for all the wxYield and wxGetApp()::Yield occurrences where Audacity is doing some drawing or already in the process of responding to a GUI event, I replaced them with ::wxSafeYield. Replaced all the remaining wxYield calls with calls to wxGetApp()::Yield().
Haven't been able to replicate the bug since these changes. Please test.
