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. ;-))
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.
We previously had both 'modules' and 'plug-ins' and the files are called things like mod-script-pipe.dll. Three different things. From a user's point of view it is easier to think of them as modifications to the basic program, like mods in Minecraft. Hence the name change. The search path now has 'mods' in it rather than 'modules'. Didn't see a need to rename the 'Modules' source code as programmers know what modules are and the mods are modules too.
Previously MultiDialog attempted to centre on parent dialog, but there was a NULL parent. Now the application top window is used. Dialog shows centred, for example when there are missing block files. If the top window is a WX_STAY_ON_TOP, we move our dialog to the left, as otherwise it would be partially hidden.
Previously Audacity would ask about enabling a module whilst the splash screen was showing. For some as yet undetermined reason the MultiDialog and Splash Screen are incompatible. Possibly it's related to doing a ShowModal before a full application exists. The not ideal workaround is to now delay showing the splash screen until after the modules have been loaded.
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.
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.
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.
Removing duplicate code from LoadModules, at the expense of making ModuleManager::Initialize more monolithic.
Make MultiDialog a bit more general.
Remove a few warnings.
Some logging has been turned back on when loading libs, we could turn it off again.
To test you could compile mod-nyq-bench and make sure it is available on the bottom of the 'View' menu, then unselect it in the Prefs -> Modules an retry.