... It mentions some wxWidgets types in its interface, but these are in the
acceptable utility subset of wxBase that we still consider GUI toolkit-neutral.
... These can happen in only two ways, using the application: from the Tools
menu, or using the Windows intaller program.
A review of all uses of wxFileConfig::DeleteAll() proves this.
The one special BoolSetting object was moved from UpdateManager to Prefs.cpp to
avoid a dependency cycle among source code files.
a) Fixed root cause, which is conversion of a
negative integer to a large unsigned, leading to
a very tall track.
b) Improved mitigation (in projects that already
have over tall tracks) by setting a smaller minimum
for the allowed size.
... A call graph browser easily shows that the extra generality of fetching
samples in some other format is only used in Benchmark -- where the format is
always the same as what the track is constructed with.
This makes re-verification of the claims in comments two commits ago easier.
... The first is an example of a Setting with a computed default value.
Also making a new file to hold them, separate from the GUI that changes them
in QualityPrefs; fewer things depend on QualityPrefs
... Giving many examples of use of Settings objects. Many other rewrites like
this should be made to eliminate as many direct uses of gPrefs as we can.
Don't rely on long distance coincidences of literals for paths or defaults.
For each of several paths like /AudioIO/Host, all uses of that path are replaced
with use of a global Settings object defined in one place, in AudioIOBase. The
object also gives the benefit of caching the last-read or written value.
Other users of those preferences must then include "AudioIOBase.h" to make the
dependency explicit at compile time.
It should be checked that no other mentions of those paths remain in the source,
and that there was no unintended change in default values.
This also inverts dependency of AudioIOBase on RecordingPrefs, which is GUI for
changing some of these settings.
... This makes it impossible to forget to include the EXPERIMENTAL definitions
(such as when cutting and pasting code) and so get unintended quiet changes of
behavior.
The EXPERIMENTAL flags are now specified instead in new file Experimental.cmake
Completing the update by John Colket. The plan always was that
these new 'repeat' entries were optional commands bindable to
keyboard shortcuts by advanced users.
Users visiting the menus can re-select the item they want.
For these menu users it would be confusing/overload to list
these repeat commands in the menu. Repeat last effect in the Effects
menu is more important. It is there in the menu to signal to
users that there is the Ctrl+R key binding for it.
