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.
Current options:
Publisher: name (the closest to what we have now)
Name (doesn't include the publisher, just a straigt up alpha sort
Publisher (creates submenus based on the publisher)
Type (creates submenus based on the type, VST, Nyquist, etc.)
And the Linux method of creating submenus based on number of items
is available to all and you can choose how menu you want per submenu.
I had to bring this back since I'd removed it when for the new effects
and I figured why limit it to only Linux...
Check it out in Preferences (effect page).
You'll also notice that the effects page is starting to talk about
plugins. That will progress further (baby steps) so bare with me
for just a bit more.
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.
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 2...
Improve performance of selection via Selection bar
This provides a similar type of speed up when selecting with the keyboard via
the Selection toolbar.
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
Make Snap To project specific
This makes the Snap To setting in the selection bar project specific. Changing
it will no longer affect other open projects.
The state is saved to audacity.cfg when the checkbox is changed. This means
that the next project window to open will start with the new value. (As it
should be).
At bottom of http://bugzilla.audacityteam.org/show_bug.cgi?id=137#c17:
> I noticed that although when we open the same project a second time with File >
> Open or File > Recent Files we show an error "is already open in another
> window", there is no block on executing the .aup from your file manager and
> opening as many copies of the project as you like. I had not done that when
> Audacity moved the files around in error the first time, but can we block this
> anyway?
This is a different bug from Bug 137, repeatable, and I think lower priority. But I went ahead and fixed it with this commit.
Also fixed previously unnoted bug where AudacityApp::MRUOpen() returned true when it actually failed to open the file. Also removed AudacityApp::OnMRUProject() cruft.
Unfortunately, it still creates a new, empty project window on Win Explorer open whereas Open and Recent Files commands do not. I think that constitutes a new, separate P5 bug.
Overall, this is another aspect of what I was talking about in http://bugzilla.audacityteam.org/show_bug.cgi?id=322#c26. Opening files vs projects got conflated for convenience, but this code is hacked in some regards, rather than being a good design, and that's why this type of bug shows up.
2. Save user's preference for enabling linking
3. fix a bug by which changes to global prefs like SWPlaythrough were not
visually reflected in other open projects.
