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.
Needed to redo a bit of code so that effects would work
without the rack in the middle. I wanted to disconnect
it completely as I'm not sure it something that will be
kept around.
During realtime preview, effects will be applied in the
order their dialogs were opened...hmmm...what happens
if they don't have a dialog??? I look into that.
Fixed the focus target for windows when cycling among
active windows as suggested by David B.
Fixed plugin registration if the plugins were located
in the "Plug-ins" folder. I believe this problem may
have played a role in the duplicate menu items.
This also now shows a new green 'play cursor' when ctrl is held down on wave track, and shift being held down is signalled by a cursor change to finger-pointer too.
I also accidentally enabled EXPERIMENTAL_MIDI_OUT. We may disable that in December for release. Leaving it in for now.
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. ;-))
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 do not now prompt about new modules at start up, unless you set a module to 'ask'. This means we can ship experimental modules with Audacity. Users can enable them if they want to, but aren't troubled by them otherwise.
Anything to do with modules and prefs is currently under EXPERIMENTAL_MODULE_PREFS and turned off.
We never load 'out of date' modules (but do allow modules to interrogate the current prefs and 'pretend' they are that version. The 'Aurora' plug-ins do that).
If a module is 'out of date' we provide the name in a user-facing message and actual location in the log, just in case the user has a number of versions in different places (untested).
We currently don't remember the users preference for loading each module, but could extend this. We would need an extra button in the ShowMultiDialog of ModuleManager::Initialize and then store the preferences in prefs. That would need a more sophisticated entry in prefs->Modules to enable a user to change their decisions.
