The 'easy' way to patch wxWidgets 3.0.2 is to copy the modified files over the 3.0.2 installation. Updated text explains what is changed from default wxWidgets.
This gets FileDialog updated and working on Windows. It also
removes removes the "wx3" build configurations and makes the default
Debug and Release builds wx3-only.
Still need to get VSTs updated.
This changes the way "unofficial" Inno Setup translations
are handled.
The first time a user compiles the .iss, the "unofficial" translations
will be downloaded to:
C:\Program Files (x86)\Inno Setup 5/Languages/unofficial
Any translations supported by Audacity that do not have an Inno
translation will be automatically created from the Default.isl in:
C:\Program Files (x86)\Inno Setup 5/Languages/dummy
This is all handled by the Inno Preprocessor. Powershell is used
to do the actual download.
Once downloaded, they will not be downloaded again, so if updates
are made, they will need to be deleted from the above directories
and allowed to download again.
In addition, I extracted the "Reset Preferences" translations from
the Audacity .po files and added them to the .iss file.
Audacity private Inno translation files are still supported in
win/InnoSetupLanguages, but I've removed the samples I'd previously
committed.
While not exactly related to this change, there were 2 languages
that weren't being set properly after being selected during
installation:
ca@valencia (Valencian)
bs (Bosnian)
The reason Valencian wasn't be displayed in preferences was twofold.
It was incorrectly named and the search loop in Languages:GetLanguages()
didn't include a range sufficient enough to pull the Valencian info.
The Bosnian language is supported by wxWidgets 2.8.12 (it is in wx3)
so, even though we have a translation, it was unavailable for
selection.
The changes required to fix those issues were:
1) Renamed ca@valencia to ca_ES@valencia
2) Instead of iterating over all wxWidgets languages and trying to
match them with our translations, I reversed it. It now iterates
over our translations and asks wxWidgets for the associated
language info. This provides support for both of the above
languages.
3) By doing #2, we are now able to add additional user languages that
may not yet be supported by wxWidgets. So, I added the Bosnian
language info.
This brings the builtin, LV2, and VAMP effects inline with the
Audio Units, LADSPA, and VST effects. All effects now share
a common UI.
This gives all effects (though not implemented for all):
User and factory preset capability
Preset import/export capability
Shared or private configuration options
Builtin effects can now be migrated to RTP, depending on algorithm.
LV2 effects now support graphical interfaces if the plugin supplies one.
Nyquist prompt enhanced to provide some features of the Nyquist Workbench.
It may not look like it, but this was a LOT of work, so trust me, there
WILL be problems and everything effect related should be suspect. Keep
a sharp eye (or two) open.
I say possible because I can't fully test it as my motherboard
audio device doesn't show up in Windows (don't know why yet).
So, because of that and because this "fix" needs a little discussion
amongst the troops, I've ifdef'd it with EXPERIMENTAL_HAVE_DEVICE_CHANGE
and have disabled it by default.
What is does is it sets up a device change listener and performs an
automatic rescan when a change is detected. (That's the part that
needs discussion.)
These are mostly under an EXPERIMENTAL_ #ifdef. Also has a change for the prompt string for preferences so the displayed keybinding is adjusted when in multitool mode.
1. Put the new files at the proper level of the Solution Explorer tree.
2. Fix a tiny tiny inefficiency in RotateHistoryWindows().
3. Do not use leading zero-padded windows when gathering statistics.
4. Hamming windows are in the advanced menu of choices, following Federico Miyara's suggestion.
* Removed duplicate paragraph about instructions for Cygwin.
* Restored Leland's added hyphens for headings. :-)
* Reduced STEP 1 to be less redundant, and to only link to wxWidgets.org, rather than the places they are currently storing downloads, which also reduces their version numbers that we need to maintain.
* Step 2.2: Changed remaining ref to 3.0.2 back to 2.8.12.
* Step 2.3:
** reordered the first two paragraphs, so you get the warning about pht.h before getting instructions that say "Build" (and changed them to be about build configuration, not actually doing the build).
** Added information about "audacity-src\win\wxWidgets_additions\window.cpp" to avoid editing the file.
** Restored the paragraph about the 5 core wxWidgets libs we use. Saves build time, and without that paragraph the subsequent "Because of dependencies..." makes no sense -- the dependencies are specified by those 5.
* Step 4:
** Restored the steps 4.1 - 4.8. Good to have, for those who don't already know how to do it this way.
** Restored the instruction about how to alternatively set WXWIN via cmd.exe, and made it explicit that's what it referred to. For lot of devs, that's easier.
* Step 5.3: Removed refs to LAME and FFmpeg, per discussion on -devel.
* typos and rewordings
I've added some of the new plugin stuff to LV2, Nyquist, and
Vamp so that they play better in the new system. They no
longer get bunched in with the Audacity effects when sorting
or grouping the menus. They have not been fully converted
but they should be good for 2.1.0.
Nyquist plugins now include ";author" and ";copyright"
statements.
Added the 4 new Nyquist plugins to the Windows build.
Audiounits are still coming...had to push them to the back
burner to get this other stuff out of the way.
Scanning for new plugins has been improved so that newly
discovered ones will be shown to the user when Audacity starts.
Effects menu sorting has been fixed and improved.
Disabling effect types in Preferences works again and you
no longer have to restart Audacity for them the change to work.
Effect usage in chains works again.
Plugin registration dialog code simplified a bit.
Group names in the pluginregistry are now base64 encoded. I
never really thought about it, but wxFileConfig group names
are case insensitive and since I was using the group name as
the plugin ID, I ran into a conflict on Linux where there
were two plugins with the same name, just different case. (And
they were different plugins.) Hoping all of this will change
when/if the config file gets converted to XML. (wx3 if finally
including XML support)
A fair amount of cleanup of this new code has been done and
will continue as more stuff is converted.
The big thing is the common efffects UI. Right now Ladspa and VST
have been converted to use it and Audiounits will be next. It makes
everything nice and consistent while reducing the clutter in the
dialog.
Other goodies are:
Ladspa effects now show output controls when supplied by the effect
Ladspa effects now work fine as Analyze type effects
Ladspa now has user presets
VST effects dialog is now less cluttered...leaving more room for the effect
Ladspa and VST effects now share a common UI
Ladspa and VST effects are now usable in chains
Ladspa and VST effects now handle user presets the same way
Currently active effects settings automatically saved and reloaded
Can now do numeric range checking on input fields.
And, as always, plenty of critter squashing.
This also (hopefully) corrects some additional problems in general
realtime support. Particular focus should be given to the handling
of various combinations of stereo, left channel mono, right channel
mono, and true mono as this has been a particularly troublesome
area.
I've added another project to the Audacity solution called
wxWidgets-2.8.12. And updated the compile.txt file with
instructions on how to build everything.
It automatically copies our setup.h and the fixed window.h
to the proper locations in the wx build tree.
It uses NMAKE to build wxWidgets using the makefile in the
wx tree. (No, I did not try to duplicate the wx project
files. ;-))
Give it a try. I think you'll be surprised how easy it will
be for new users.
I've made it where you can enable and disable via experimentals:
EXPERIMENTAL_REALTIME_EFFECTS
EXPERIMENTAL_EFFECTS_RACK
You will notice that, as of now, the only effects currently set up for
realtime are VSTs. Now that this is in, I will start converting the
rest.
As I start to convert the effects, the astute of you may notice that
they no longer directly access tracks or any "internal" Audacity
objects. This isolates the effects from changes in Audacity and makes
it much easier to add new ones.
Anyway, all 3 platforms can now display VST effects in graphical mode.
Yes, that means Linux too. There are quite a few VSTs for Linux if
you search for them.
The so-called "rack" definitely needs some discussion, work, and attention
from someone much better at graphics than me. I'm not really sure it should
stay in as-is. I'd originally planned for it to be simply a utility window
where you can store your (preconfigured) favorite effects. It should probably
revert back to that idea.
You may notice that this DOES include the API work I did. The realtime effects
were too tied to it and I didn't want to redo the whole thing. As I mentioned
elsewhere, the API stuff may or may not be very future proof.
So, let the critter complaints commence. I absolute KNOW there will be some.
(I know I'll be hearing from the Linux peeps pretty darn quickly. ;-))
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.
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.
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.
From what I can tell, the only thing that is "lost" because of
this is the possibility of using C++AMP. Not really an issue.
And we don't have to provide different runtimes for XP and
win7+. They all use the same redistributable package.
Renamed the VS2008 solution instead of removing it
to give people time to get VS2013 installed.
Will remove the VS2008 solution and project files
after a while.
This change is believed to be a direct refactoring that does not change functionality. It paves the way for more complex kinds of selection, such as selections involving frequency as well as time. It also reduces risk of left and right edges being swapped in future code using SelectedRegion, as the default is to swap on assignment if needed.
To test on Windows:
1) Install gstreamer 1.0 devel and runtime
2) Add an GSTREAMER_SDK environment variable which points to the
gstreamer base directory
3) Uncomment USE_GSTREAMER in configwin.h
This was NOT just a straightforward conversion. It took days to
figure out why projects kept building over and over again, so
committing is the best way for people to kick the tires.
These are completely separate from the VS2008 project files, so
they do not affect current build process.
The are pretty darn slick. There's an integer one and a floating point
one. They support automatic range limiting (ex., you can't even type a
number outside of the range), proper number formats (ex., you can't
enter a decimal point in an integer field), you can't enter bogus
numbers like "0.3-.2", thousands separators are supported, decimal
precision may be specified and proper number formatting for string
values (or automatic conversion to int, double, float, etc.).
This is an older one...originally from 2011. Bug says it all, but basically it allows logging
to begin immediately upon startup for all platforms. And it has multithreading protection, so
it should now be safe to log from the non-GUI threads.
For Resample.* and QualityPrefs.cpp, this commit has my restructuring for distinguishing constant-rate vs variable-rate resamplers more generally. I think it's complete and ready for const-rate, but I have more review and testing to do for the var-rate cases.
Variable-rate resampling is not implemented here, so Time Tracks are still broken, but this is a milestone in getting to a more general and correct structure.
Also I think this fixes AboutDialog issues Steve noticed.
James Crook
Leland Lucius
Paul Licameli
David Bailes
yam
v.audacity@gmail.com
v.audacity
martynshaw99
windinthew@gmail.com
lllucius
james.k.crook@gmail.com
lllucius@gmail.com
windinthew
benjamin.drung@gmail.com
clayton.otey