... Use correct symbolic constants in three places (no effect);
use proper theme color for the two pixels per track that are left of and
above the shadow (small effect when not Classic theme)
This revised fix:
- No longer attempts to drive "Default sample rate" from the selection toolbar.
- No longer drives 'Project rate' direct from prefs. It's usual it comes from the project.
- Instead 'Project rate' in the project might change if 'Default sample rate' pref is updated, but ONLY if the project has no tracks.
- When 'Project rate' in the project is updated, that is now always signaled to the selection toolbar. Previously it wasn't.
This change is inspired by the plan to eliminate GetLinked() in 2.3.1. Logically we shouldn't be exposing a boolean 'linked' in scripting, but instead a channel count.
The Project Rate in the Selection Toolbar and in the Preferences dialog are now the same thing. They ALMOST were before, causing confusion, and this bug.
This means that the fancy mechanism to set 'other' rates in Preferences is moot, since the Selection Toolbar bar does not have that option. 49000 will be overridden by 48000 for example.
This is not a proper fix, as we do not fully understand the problem - which is in release builds only.
It may be enough though to get us through to release.
... This was motivated by punch and roll recording: it appears most convenient
to pin the head for recording purposes, and drag it near the right, but when
stopping and finding the splice point for the correction, it is better to
scrub unpinned.
Logic changed to delay pause by one frame, if there is a need to fade out.
So we calculate whether we are already faded out, and if we are pause, otherwise delay the real pause for one frame.
Now we show "11:07:29 +" for a time 100 years, 11 hours, 7 mins and 29 seconds in the future, rather than ASSERTing.
The + should probably be mentioned in the manual. "In the countdown, times more than 24 hours ahead aren't shown fully. A '+' sign after the time indicates that it is more than a day ahead."
Problem: When using WASAPI on Windows, the last "latency buffer length" of a selection is not played. This is a fairly nasty bug for those relying on playback when making fine adjustments to the position of the cursor, or the start or end of selection.
During playback the "latency buffer length" has no effect on the actual latency of the playback, but the playback cursor is positioned as if the "latency buffer length" did have an effect, that is, it is positioned by this amount after the audio being played.
So an obvious workaround is for the user to set the latency buffer length to zero when using WASAPI. However they then have to remember to change it if they use another audio host.
Fix: The real problem is presumably a portaudio bug, but this fix just hard codes the workaround given above. For playback, when using WASAPI, set the suggested latency to 0, regardless of user setting.
... but we don't need to make it as precise, using steady_clock.
Do this so that the Audio thread doesn't read the same polling message twice,
halting the scrub. It's all right that it might miss one of the messages
instead.
