... also restore the intended meaning of "allowDup" (for debugging checks only),
which had never been properly implemented because the label, not the
accelerator, was scanned for it; see commit f2f7568
... and recompute popup menu tables that depend on preferences.
The code for labels in the rulers was unsatisfactory because
(1) rescanning and editing the post-translation strings is a hack to avoid, and
(2) separating the hints like "Shift-Left-Click" with a tab character made them
invisible on Mac. So instead, append strings like " (Shift-Left-Click)"
... because the two macros have the same expansion, and are both checked for
in the --keyword arguments passed to msgfmt by locale/update_po_files.sh.
This commit makes ONLY such changes, and comments in Internat.h. It is big
but quite harmless.
The intention is to introduce a type distinction in a later release, by defining
XXO differently. XXO is used where & characters in strings (for hotkeys of menu
items or control prompts) are permitted, XO where not.
... Moved many misplaced ones, which msgfmt would not have extracted into
audacity.pot.
Duplicated some of them, to appear with related but distinct msgids.
Added a few new comments.
Deleted one that was no longer needed in ProjectManager.cpp.
Fix was provided by Hans Petter Selasky with the following comment:
This is a regression issue after:
Move the scrub mouse event handler into ScrubUI...
Where:
if (mWindow)
mWindow->PushEventHandler(&mForwarder);
was removed from the Scrubber() constructor function and
not from the ~Scrubber().
Currently AudioIoCallback::ScrubState::Get(), inserts a period of silence the first time it's called because at this time Scrubber::ContinueScrubbingPoll() has not been called, and so message.end has not been set to an appropriate value.
In the case of keyboard scrubbing and play-at-speed, the initial speed is already known, so message.end can be set to this value, removing the need for an initial silence.
The start of keyboard scrubbing and play-at-speed are now faster (the latter very much faster).
... 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
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().
- There are two new commands: Scrub Backwards and Scrub Forwards.
- These commands appear on the Transport sub menu of the Extra menu.
- The commands have default shortcuts U and I, and are in the standard default set.
- After pressing one of the two keys, playback continues until the key is released. (Note that this means that the command on the Extra > Transport menu can't actually be used for scrubbing as it executes a KeyDown immediately followed by a KeyUp, but the menu items are needed so that the current keystrokes can be seen and changed.)
- Playback starts from the cursor position, or the start of a time selection if there is one.
- The speed of playback is determined by the zoom level. If the zoom level is normal, then the playback speed is one quarter of the normal playback speed. Zooming in (Ctrl + 1), halves the playback speed, and zooming out (Ctrl + 3) doubles the playback speed. There are minimum and maximum playback speeds of one sixteenth, and four respectively.
- You can scrub to the end of the audio, even if there is an initial selection. In other words, scrubbing forwards does not automatically stop at the end of the selection.
- Normally, when one of the keys is released, the position of the cursor is set to the time when the key was released.
- If during the time one of the keys is pressed the left bracket and or right bracket keys are pressed to set the start and/or end of the selection, then when the scrubbing key is released, the change to the selection made by pressing the bracket keys is preserved - the position of the cursor is not set to the time when the key was released.
This implementation is affected by two existing bugs:
1. Bug 1954 - Clicks may occur starting/pausing play-at-speed or Scrub. (See comment 19 and attached image).
2. Bug 1956 - Windows: MME and WDS playback cursor is buffer length ahead of actual audio playing. This means that on Windows, WASAPI is preferable if scrubbing is being used for the accurate positioning of the cursor.
... and deduce whether to exclude from macros inside NewIdentifier, simplifying
argument lists further
Also fix the localization of "..." added to names by PluginMenus.cpp
... this is a remnant of the abandoned experiment that put other buttons in
the ruler besides the pinned play head
See commit 6a3613e8e97da5164da881a179f1b64ac098d472
... which was redundant with what happens in the yield to idle events in
ProjectAudioManager::Stop.
This removes direct dependency of ProjectAudioManager on ControlToolBar.
And remove another #include we don't need
... in places that need the TrackPanel but only to invoke common wxWindow
methods on it.
This eliminates direct use of TrackPanel by Scrubbing and ProjectWindow
ControlToolBar, after we make a system to register functions that calculate
necessary minimum widths for status bar fields.
Also let Scrubbing.cpp register its own strings.
Also be sure to size the status field sufficiently for "Playing at Speed".
... so most calls to ControlToolBar::SetPlay are removed. One remains in
TransportMenus, which will not be problematic for untangling dependencies,
and one remains where the toolbar remakes its own buttons.
But the routines that start and stop the streams, importantly, don't use it.
... Move that into ProjectAudioManager instead, and update the button, only to
reflect it, in idle time.
However, AudioIO also has its mPaused member variable, and it is not obvious
that it was always kept the same as the button state. No attempt was made
here to identify and fix any bugs, but only to preserve behavior.
