This relies on three new nyquist scripts to actually do the editing. The peak-snapping code in FrequencyWindow has been extracted into a new class, SpectrumAnalyst, to provide peak-snapping in spectrogram too.
These are mostly for getting it to build on Linux, but I've
also created new configs in Visual Studio to make it easier
to switch between wx2 and wx3.
For Linux, you have to tell configure where to find the wx3
version of the wx-config script and, since some distros build
wxWidgets v3 against GTK+ v3, you may also need to enable
gtk3 with something like:
./configure --enable-gtk3 WX_CONFIG=/usr/bin/wx-config-3.0
On Windows, I've added "wx3-Debug" and "wx3-Release" to the
existing "Debug" and "Release" configurations.
They depend on you having your WXWIN environment variable
pointing to your wx2 directory and a new WXWIN3 environment
variable pointing to your wx3 directory. For instance, I
have:
WXWIN=C:\Users\yam\Documents\wxWidgets-2.8.13
WXWIN3=C:\Users\yam\Documents\wxWidgets-3.0.2
Doing this allows you to switch freely among the 4 configurations
without having to get out of Visual Studio and monkey around with
the environment.
The project files will also add the location of the wxWidgets DLLs
to the PATH when running Audacity from within Visual Studio. They
add %WXWIN%\lib\vc_dll or %WXWIN3%\lib\vc_dll at the beginning
of the PATH variable as appropriate.
I expect that once we convert to wx3 we'll just drop back down to
the normal Debug and Release configurations, but this should make
switching between wx2 and wx3 much easier during the transition.
A complication is that the 'OnEventLoopEnter()' gets called many times, so we need to only call FinishInits() once. There is something else not right with the dialog this early on, so for now I have moved it back into the OnAppInit() which works on both wx2.8.12 and 3.0.1.
This is after reading a note in the release notes for wxWidgets 3.0.0. We need an event loop running to show a dialog in 3.0.0 (even though the splash screen works without).
Review did not like 'mods'. Was felt to be too non-standard. Note that we gained a '?' on a question to the user, an internationalisation hint about the word 'modules' and the words 'the Audacity Manual' (note caps) in making and 'reverting' this change.
We previously had both 'modules' and 'plug-ins' and the files are called things like mod-script-pipe.dll. Three different things. From a user's point of view it is easier to think of them as modifications to the basic program, like mods in Minecraft. Hence the name change. The search path now has 'mods' in it rather than 'modules'. Didn't see a need to rename the 'Modules' source code as programmers know what modules are and the mods are modules too.
This ensures that the config file remembers a 'fail to load'. We set status to fail before loading a module, that now gets written out to the config file because we flush prefs, the dodgy module loads and crashes, and next time Audacity knows it's a fail. If instead the module loads and does not crash on load, the original status (enabled or ask) is written back to the config file.
Previously MultiDialog attempted to centre on parent dialog, but there was a NULL parent. Now the application top window is used. Dialog shows centred, for example when there are missing block files. If the top window is a WX_STAY_ON_TOP, we move our dialog to the left, as otherwise it would be partially hidden.
Previously Audacity would ask about enabling a module whilst the splash screen was showing. For some as yet undetermined reason the MultiDialog and Splash Screen are incompatible. Possibly it's related to doing a ShowModal before a full application exists. The not ideal workaround is to now delay showing the splash screen until after the modules have been loaded.
With the move to VS2013, we no longer need the DirectX SDK
and, therefore, we can always enable DirectX support.
If an individual user doesn't want DirectX support, they can
always disable it for their private copy. But, I believe we
will always release with DX support, so it is now on always.
For those that have the DX SDK installed just for building
Audacity, you may now remove it and you should still get
DX support in Audacity.
With the addition of the preview button, it became evident
that if an effect were to return text instead of audio, the
processing loop would not stop properly.
And he also found a case where the debug state wasn't reset
after using the debug button. If this was following by the
preview button the next time the effect was used, the debug
window would reappear before the preview.
The problem was because I added double buffering to reduce
flicker on Windows. But, OSX already does its own buffering
and adding more causes text to be rendered incorrectly.
This happened a long time ago on the track panel and when
Bill gave the screenshot, my aging brain slowly remembered
the cause.
The original fix silently change sizes of collapsed wavetracks. That's not visible, but will be seen when they are next unminimized. To be consistent with the new size calculation, we now only changes the sizes of the unminimized wavetracks.
