Works by un-full-screening before closing. Patching wxWidgets was needed to
make that work correctly after full-screening by clicking on the green circle
in the title bar, but that fix is not needed for full screen after command+/
... many details will need further work, but basic navigation among
pushbuttons with control-alt-arrows and presses with control-alt-space will
work.
Shift-ctrl-alt-down on track panel works to navigate among individual tracks,
and shift-ctrl-alt-up to escape back to the higher level.
... Busy-waiting will happen on Mac when modal dialogs are open, and a LADSPA,
VST, or AudioUnits effect is also open with "fancy" interface.
Busy-waiting will not happen for modal dialogs at other times.
Enh1444 is to make pinch and spread gestures work.
Bug1435 is to bring focus rings back for types of controls that lost them in
version 2.1.2. This importantly includes pushbuttons and choice controls
(drop-down menus). Less importantly, date picker (as in the Timer Record
dialog) and Listbox (as in the dialog to choose label font).
There is one more type of control that lost focus rings, and is not fixed:
List controls (distinct from list boxes), such as in the Manage Curves dialog
that opens from Equalization.
... This poor imitation of the standard Mac Window menu only includes
Minimize and Zoom.
But this may be adequate for the complaints in Bug1198, when the yellow title
bar button is hidden and unreachable.
In addition, the Xcode project can now build against the 10.6
or 10.7 SDKs. All that is needed is to change the SDK version
and the other settings will change automatically.
It had been causing problems in Unity for a while now and they
were missing on OSX as well in wx3. So, the old menu Open/Close
method of hiding has been removed and replaced with an event
filter/monitor which looks for wxEVT_CHAR_HOOK events to pass
key events to the handler that has the keyboard captured.
Main change is that VST GUI support is now integrate with new Cocoa
views. Direct support for VST Cocoa views (via Cockos extensions:
http://www.reaper.fm/sdk/vst/vst_ext.php) has been added.
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 provides additional improvements and updates for building
Audacity using Xcode 5.1 or above.
The whole configure/makefile system is no longer used during
normal builds. During library additions/updates it used to
regenerated the headers in mac/config.
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.)
They now work on Yosemite.
AudioUnits with a custom Cocoa UI now display graphically
instead of reverting to the generic view
The Cocoa version of the generic view is now used when
needed...instead of the Carbon version.
The order of UI preference is Cocoa, Carbon, Generic,
unless force to Generic view user setting.
They now support realtime preview.
They also support dialog resizing as I found many that
scaled nicely (mostly Apple's).
Uses the new Effect format so now supports user and
factory presets.
NOTE: Be VERY critical when testing this as I've
never written Objective-C or Cocoa code
before!
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 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. ;-))
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.).
Relocates the translation tables to the bundle
This will change the location of the translation tables from:
<root>
Audacity.app/
Languanges/<langcode>/
to:
<root>
Audacity.app/Contents/Resources/<langcode>.lproj/
This will allow the menu items to be translated as expected.
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.
Fixes for PPC when building libsoxr universal.
Helpful compiler/precompiler/linker environment variables for Lion/Mountain Lion.
Sorted out which resampling library was used in each of the three Configure targets, fixes an annoying error about trying to modify a nonexistent config.h file.
with libsamplerate rather than libresample.
Changes needed to ensure that libsamplerate builds a universal library correctly.
PPC version has not been checked.
which was caused by the fix for Lame and FFmpeg detection. Now,
the Audacity.sh script will only be used for "release" versions.
2) Provides a new "Manual" target that the developer can use to
retrieve the Audacity manual and put it in the "help" directory
to facilitate testing.
3) Provides a new "Plugins" target that the developer can use to
build the 3 Ladspa plugins that are distributed with Audacity.
They will be built into the "plug-in" directory. The main
reason for this one was because no one could remember how to
build them, so now it will be available to everyone.
4) Supports the "install" build action for creating an output
direcotry that is fully distributable. (DMG and ZIP creation
will be added soon.) This provides the ability for anyone
to create Mac releases.
This should fix the detection problems on the Mac and may even help with issues
on Windows and Linux.
On any of the platforms, the main issue is the search path for libraries and
how absolute path names are handled. The Mac seems to be especially
susceptible since there isn't one concrete location where libraries are stored.
Windows handles absolute paths differently and allows runtime updates to the
environment variables (and if push comes to shove, provides the
SetDllDirectory() function), so if problems still exist, they should be easy to
circumvent.
This patch does three things:
1) It adds a shell script on OSX that takes care of starting Audacity after
reassigning and clearing the DYLD_LIBRARY_PATH environment variable. This will
allow loading of libraries from their absolute path rather than searching
DYLD_LIBRARY_PATH first. This script should be transparent to the user, but it
will affect people running Audacity with gdb as they will have to specifically
target Audacity.app/Contents/MacOS/Audacity instead of the Audacity.app bundle.
Not big deal really. If ppl no enough to use gdb from the command line, they
should be able to figure it out.
2) It corrects detection of a monolithic FFmpeg library. This is one where
avformat, avcodec, and avutil have all been linked into one large library. The
main issue here was that under OSX and Linux, looking for symbols that should
reside in avutil and avcodec, would always succeed since dlsym() on these
platforms not only scans the requested library, but any dependent libraries as
well. And when avformat was loaded, it would pull in it's dependent libraries
as well.
Another issue here was the if it was determined that the library was not
monolithic, the library was never unloaded, so those dependent libraries may
have come from the wrong location since they would have been loaded via the
normal search paths and not by absolute path name.
3) It adds a method to FileNames which returns the full path name of a loaded
module that contains an address. In the case of FFmpeg, it is used to verify
that a routine from a specific library is actually being used from that library
or not. It is also used to show (in Help->Show log) the directory from which a
library was actually loaded.