... Now they are treated more alike:
Each is shown or hidden (not enabled or disabled) as the corresponding sub-view
of the wave track is shown or not.
Each has separator lines above and below.
They are shown (one or the other or both) after the choices for sub-views, and
not near the bottom of the menu.
This makes the TCP menu one item shorter in the default case that you view only
waveform.
... Problem with static initialization order of ReservedCommandFlags, caused
wrong enablement of menu items (at least on Mac), such as Plot Spectrum or
Contrast enabled when there was no selection
... which is not yet used for anything.
It could be used to describe textual paths for attaching plug-in menu items.
Strings are only path local, not necessarily globally unique, and may be
left empty for separators and for groups that should be transparent to
path identification.
It may also be empty for certain sub-menus, such as those that group effects
according to the changeable criteria in Preferences.
... Except a few where project or plugin manager state or preferences are
needed to compute the items, so evaluation is delayed, often inside lambdas
Comment "Delayed evaluation" wherever there are exceptions
... This caused visible anomalies, for instance when dragging the stereo track
separator between channels. Numbers from one channel used to be drawn over
the ruler of the opposite channel.
... in Wave track context menu and SetTrackVisualsCommand
Instead, discover them through a registry.
This eliminates some duplication of string constants and prepares for
non-intrusive generalization to more kinds of sub-views.
This makes the command agnostic about which subview types are known, but the
context menu still has special case treatment for Spectrogram Settings and
Wave Colors.
... To be consistent with the rearranging of sub-views, and with general UI
guidelines.
The hover cursor is an open hand, and the dragging cursor is the closed hand.
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.
