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.
If you can believe it, this whole big mess is
just to get localized effect labels back into
the menus.
I sure wish I'd had a little bit more time to
finish up all of the effects. It sure would
be a lot cleaner (code wise).
I'm 100% certain I found the cause this time (r13739 was
still needed though).
There's a design flaw in wxMenuBar::RebuildAccelTable() that
will always leave the last accelerator active as they are
removed from the menus.
For the Edit menu, that will be "Move Cursor -> to Track End"
because of the way the submenus are traversed. And because that
fella happens to have an unmodified character for an accelerator
it can't be used in a label track until another menu is opened
and closed.
The workaround is to nullify the accelerator table when a menu
closes.
Whenever a menu is NOT open, the accelerator keys are
stripped from the menu items so that the O/S doesn't even
know that accelerators are being used (we do it internally).
While this stripping was being down when the menus are set
up, it was NOT being down when the Undo and Redo menu items
were modified to include the "last action".
So, the fix is to strip the accelerator then as well.
Removed a line in AddItem() and InsertItem() that didn't
seem to make sense (especially given the comment). However,
it caused an issue where the key assignment would persist
for one last time after leaving Preferences. It would then
act as desired.
This MUST be tested by everyone on as many platforms as you
have access to...reason:
This removes a very old piece of code (May 10, 2003) in the
command manager that worked around a problem in GTK where
accelerators could not be changed again after the initial
menu setup.
While there is another way to fix this bug, remove this old
code is actually a better way AS LONG AS it doesn't break
anything else. So far, it's looking like it is no longer
needed.
But, I'll be trying as many combinations of changing shortcuts,
entering/exiting preferences, swapping shortcuts, etc, as
I can on Linux, Windows and OSX.
But, the more ppl trying to break keyboard shortcuts the
better.
In case it helps, here's the comments that Dominic had in the
code:
// This is a very weird hack. Under GTK, menu labels are totally
// linked to accelerators the first time you create a menu item
// with that label and can't be changed. This causes all sorts of
// problems. As a workaround, we create each menu item with a
// made-up name (just an ID number string) but with the accelerator
// we want, then immediately change the label to the correct string.
// -DMM
With realtime preview, the keyboard user will need this to get
back and forth between the effect and the project window. Actualy,
the "problem" existed before this since the keyboard user couldn't
switch between project and Plot Spectrum windows.
The normal flags-based keyboard handling would not work since it
depends on the state of the project and requires a project window
to have the current focus.
In this new case, a modeless dialog may actually have the focus and
using the "switch window" key combo may happen in nearly any mode, like
while playing.
So, I "created" the concept of "meta" commands...ones that do not have
the restrictions mentioned above. The should be used sparingly and
you must be careful about what happens within their handlers.
Correct string formatting for:
2/15 %d + enum => %d + int
3/15 %lld + int64_t => %lld + long long
4/15 %d + int64_t => %lld + long long
5/15 %d + double => %f + double
6/15 %d + int32_t => %d + int
7/15 %d + intptr_t => %p + void*
8/15 gint, guint
9/15 %d + long => %ld + long
10/15 %n + int => %d + int
11/15 %x + int => %x + unsigned int
12/15 %f + int => %d + int
13/15 %S + wxChar* => %s + wxChar*
14/15 %d + size_t => %d + int
15/15 %d + size_t => %lld + long long
"The functions wxString::Format, wxString::Printf (and others indirectly) have become stricter about parameter types that don't match (format specifier vs. function parameters). So the bugs (that were already present in audacity before) become visible in wx3.0 as error message dialogs. I've checked all occurrences of Printf, wxPrintf, PrintfV, Format, FormatV, wxLogDebug and wxLogError systematically and made the type match."
Note (9/15): In TrackPanel.cpp, ExportMP2.cpp and CompareAudioCommand.cpp this patch supersedes related change done in r13466 because the new solution requires fewer casts and therefore simplifies the code.
Note: Many .po files are affected, and we need to be very careful about this. Incorrect "%d" and similar in translation files may lead to crashes in those languages (only). This is something we should actually have been more careful about in the past. We need to write a script to check that the "%d" and similar format specifiers match between English and translation.
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. ;-))
He wanted to help so I asked if he wanted to track them down. He agreed and
found more than I probably would have. And he said there were more, but the
rest were questionable and since he works on Windows, wasn't able to actually
test.
I give a few of the ones he did find a go and they do indeed get rid of the
assertions.
(Basically, a 64-bit/32-bit issue, easily resolved with a typecast.)
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.
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.
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.
This is part 1...
Provides some relief to the selection "hang"
This patch adds the ability for the keyboard based commands (like cursor left,
extend selection right, etc.) to know when the key has been released.
When the patch is applied the current state is saved only when the key is
released and not every time it repeats.
Here's an example of the difference it makes.
This video show the selection "hang", but also watch the CPU usage. All I'm
doing is pressing SHIFT+RIGHT ARROW.
http://youtu.be/tdMntDwGSkM
This one is the same thing bug with the patch applied. Notice that the
selection "hang" no longer occurs and look at the CPU usage!
http://youtu.be/EpXNsQ4Cky0
research into why that code had been ifdef'd in the first place and allowed
the root cause to be identified.
Now the menus are cleaned up properly, which also fixes bug #458 without
having the workaround in r12639.
Basically, the problem was that attempts were being made to manipulate
menuitems on a menu that no longer existed (after the menus were rebuilt).
One tricky aspect was that until GetActiveProject() is ready to return non-NULL, ControlToolBar::RegenerateToolsTooltips() cannot get the project's CommandManager, so cannot get the shortcuts. Changed ControlToolBar::RegenerateToolsTooltips() to be public and now call it late in wAudacityProject(). When called before the project is completely instantiated, in the rewritten ControlToolBar::RegenerateToolsTooltips(), it just sets the tooltips to the names without the keys, pretty much as now -- but I don't think users will ever see that because of the subsequent call.
Anyway, did it in a more programmatic way than the previous code, which reduces string literals duplication.
Btw, I changed the start value for the ID_PLAY_BUTTON because the former value of 0 causes FindWindow() to return the toolbar rather than the button -- wxWidgets bug.
Also got rid of some cruft and applied a few WXUNUSED.
