Previously the ID for a macro was, e.g. Macro003. However this would
not work if macros were added or deleted, since chains containing the old
macro references would now refer to a different macro. So changed to using
names.
Done by giving Macros... dialog an Expand / Shrink button
so that we can use it as just an apply-to-projects dialog, if we want.
The dialog is modal, and can be kept open whilst we work. So for example
we could put useful presets into it as macros.
- Move them around on EditChainsDialog so that dialog can be shrunk. (new column).
- Use "Files..." not "Files" as the button text.
- Take 'Apply Chain to:' out of the BatchProcessingDialog buttons, and place as separate text.
It is now populated with the CommandID and the command type.
Later we can add the command help string.
Std::pair changed to std::tuple to accommodate the extra information.
- Added the Apply-to-Project and Apply-To-Files buttons
- Derived EditChainsDialog from BatchProcessDialog so as to share code.
- Added Edit button, for people who don't realise they can click on the list.
- Clicking on list now directly invokes the parameter editing.
- Insert and Edit now insert before --END-- if nothing was selected.
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
... and similar wx "variadics," which all treat wxString smartly enough that
you don't need this.
Don't need c_str either to convert wxString to const wxChar * because
wxString has a conversion operator that does the same.
New fix. It appears to be a bug in wx3. Hiding a Modal window (under linux) can stop it being modal. So rather than EndModal() we send an event to close the window which works whether wxWidgets thinks the window is modal or not. Additionally we set the focus back to the parent window, becuase of a side bug under windows, and we new the status dialog rather than allocate it on the stack, because the status dialog is NOT run with ShowModal() which is the only time we can safely use an on stack dialog.
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. ;-))
