If one of the keyboard scrubbing keys is being held down, and the other keyboard scrubbing key is pressed:
1. With current behaviour, scrubbing in the other direction only starts when the original key is released - scrubbing stops and then starts in the other direction.
2. With the new behaviour, scrubbing immediately changes direction, and does not stop when the original key is released - scrubbing does not stop and then start again.
New behaviour:
If one of the keyboard scrubbing keys is being held down,
Problem:
On Windows, after 50ms, there is a short period of roughly zero introduced into the output. On Linux, there is also a spike which sounds like a crackle.
In AudioIO::FillBuffers(), Mixer::SetTimesAndSpeed() is called, which sets mT0 and mT1 to a small interval.
In Mixer::MixVariableRates(), all the samples in the interval are used, which means the Resample::Process() is called with last equal to true.
So when Mixer::MixVariableRates() is called again, the resampler is being reused after a call to Process() in which last is true.
It is not stated in the soxr documentation if the resampler will produce valid results in this case, and it's only the scrubbing code which does this.
I think this is the problem, and so the partial fix below avoids this happening.
Partial fix for play-at-speed and keyboard scrubbing:
For these, there is no need to reset the values of mT0 and mT1. (There is no need to allow for the sample position being used to potentially jump around.)
So for these cases, Mixer::SetSpeed() is called, rather than Mixer::SetTimesAndSpeed().
... Regression happened at 3f1fd8ced0fb5fe617ad2dd7808cd1ae2ca2c0f3
The heights were written to file, but not read back again.
This fix was done carefully to avoid making dependency cycles. We don't want
Track to depend on TrackView or TrackControls.
It's not great that LabelTrack, NoteTrack, TimeTrack, and WaveTrack now have
those dependencies, but at least they don't make cycles.
It would be better to figure out how to attach the view and controls to the
track with ClientData, then just invoke BuildAll to repopulate the view and
controls, so that they are non-null when you reach
Track::HandleCommonXMLAttribute.
... when in Multi View mode.
And what we do here is disable the menu item. The visible check indicates
which view is enabled, but you are not allowed to un-check it. While the
Multi View item appears enabled and with a check mark. That should be
suggestive enough to let the user discover how to exit multi view.
... when you shrink a sub-view then toggle it, or toggle all views off then
exit multi-view
Fix it by making GetSubViews more robust to contents of mPlacements
... because that will be needed for elimination of some GetActiveProject()
calls. Because some overrides need to find the focused track, but that may
mutate the project by setting the focused track when it wasn't yet defined.
... When it's off (default), Spectrum and Waveform buttons behave as before,
and dragging of the sub-view separator is disabled.
When it transitions to off, and the view is split, then the top sub-view takes
up the whole view.
When it transitions on, nothing visible happens.
When it is on, and you choose Spectrum or Waveform, then the corrsponding
sub-view toggles visibility.
When a sub-view is turned on by the menu item, it appears lowest.
