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.
