Ran "autoreconf --force --no-recursive" for Linux build.
Add nyquist-plug-in-installer.ny to Windows build
Add Nyquist Plug-in Installer to mac build
Fix translation strings in plug-in installer
Tidy translation code in init.lsp
Include rms.ny in Makefile.am
Add rms.ny to Linux package
Update Makefiles with: autoreconf --force --no-recursive
Add rms.ny to mac build
Add rms.ny to Windows build
This was done on a Ubuntu 14.04 system with wxWidgets 3.1.1 installed.
The resulting buildfiles successfully build Audacity on Ubuntu 14.04 (with 3.1.1) and on Travis (with 3.0.0).
This is a squash of 50 commits.
This merges the capabilities of BatchCommands and Effects using a new
AudacityCommand class. AudacityCommand provides one function to specify the
parameters, and then we leverage that one function in automation, whether by chains,
mod-script-pipe or (future) Nyquist.
- Now have AudacityCommand which is using the same mechanism as Effect
- Has configurable parameters
- Has data-entry GUI (built using shuttle GUI)
- Registers with PluginManager.
- Menu commands now provided in chains, and to python batch.
- Tested with Zoom Toggle.
- ShuttleParams now can set, get, set defaults, validate and specify
the parameters.
- Bugfix: Don't overwrite values with defaults first time out.
- Add DefineParams function for all built-in effects.
- Extend CommandContext to carry output channels for results.
We abuse EffectsManager. It handles both Effects and
AudacityCommands now. In time an Effect should become a special case of
AudacityCommand and we'll split and rename the EffectManager class.
- Don't use 'default' as a parameter name.
- Massive renaming for CommandDefinitionInterface
- EffectIdentInterface becomes EffectDefinitionInterface
- EffectAutomationParameters becomes CommandAutomationParameters
- PluginType is now a bit field.
This way we can search for related types at the same time.
- Most old batch commands made into AudacityCommands.
The ones that weren't are for a reason. They are used by mod-script-pipe
to carry commands and responses across from a non-GUI thread to the GUI
thread.
- Major tidy up of ScreenshotCommand
- Reworking of SelectCommand
- GetPreferenceCommand and SetPreferenceCommand
- GetTrackInfo and SetTrackInfo
- GetInfoCommand
- Help, Open, Save, Import and Export commands.
- Removed obsolete commands ExecMenu, GetProjectInfo and SetProjectInfo
which are now better handled by other commands.
- JSONify "GetInfo: Commands" output, i.e. commas in the right places.
- General work on better Doxygen.
- Lyrics -> LyricsPanel
- Meter -> MeterPanel
- Updated Linux makefile.
- Scripting commands added into Extra menu.
- Distinct names for previously duplicated find-clipping parameters.
- Fixed longstanding error with erroneous status field number which
previously caused an ASSERT in debug.
- Sensible formatting of numbers in Chains, 0.1 not 0.1000000000137
Configure.ac:
Upped version number to 2.1.3
Made FFmpeg and LibFlac Local
Readme.txt:
Added instruction for CFLAGS.
Use XCodebuild instructions on Mac, not autotools.
one reason is, on Mac must use patched wxWidgets 3.0.2
configure script now auto detects whether wxWidgets was built using
gtk2 or gtk3, so there's no longer a need to specify which one when
running configure.
VST support updated for wx3 under GTK.
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.)
In r13510 I had neglected to build with all local libraries and some of
them needed attention.
So, I also took the opportunity to work out the locale directory and
how to keep it unmolested as well. As a result, all locales are rebuilt
as expected, but into the "build" directory.
As a bonus you may now test Audacity from the "build" directory and have
Nyquist plugins and message catalogs available (so you can test other
languages again without havint to install).
So, again:
mkdir buildme
cd buildme
../configure
make
./audacity
You may now do:
mkdir build
cd build
../configure
./audacity
And all but one directory will remain unmolested...no more object files
in "src".
And if you look carefully, you'll see that the newly built "audacity" is
copied to the top of the build tree...no more having to use "src/audacity"
to run.
You can of course still do the configure from the top and get all of the
objects strewn about the tree.
I still haven't figured out how to keep the locale directory from getting
soiled. I'm not really sure there's a way around it really.
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.
We can't go to 3.0.1 yet as there are still build issues on
Linux and OSX. You can get Windows to build, but there's
still some display issues.
These changes should work with wxWidgets 2.8.12 as well, so
we can take our time to get things working properly before
switching over.
