... though harmlessly so. They called to nonstatic member functions of classes
with improper this pointers; though the functions did not use this.
Bind events to nonmember funtions instead. Sometimes just to empty lambdas to
consume the event and ignore it, blocking other handlers.
... it's either the source of the connection that is being destroyed, or other
object (such as an ancestor window) transitively owning it and so causing it to
be destroyed too;
or, the sink is being destroyed, and that sink is a wxEvtHandler (which is
always so for Disconnect, though not for Unbind in case Bind was passed a
member function of a non-wxEvtHandler).
wxWidgets takes care of erasing the connection in such cases.
This removes most calls to Disconnect and Unbind. Many destructors shrank to
nothing.
Notably, in case of popup menu handling, the call to Disconnect is not removable
because the object being destroyed is neither the source nor the sink.
A 4hr track used to take about 20s to cut a few samples. This is now significantly improved, to around 3s. Leland did this by
(a) moving the size calculation to when we examine the undo history, so it isn't slowing down the edits.
(b) in size calculation, using sizes that are cached rather than going to disk to find the sizes.
(c) writing the autosave file which is to an FFIle to a string first, i.e. using XMLStringWriter as a buffer for XMLFileWriter.
Step (c) may also make autosave marginally safer, as the risk of a partially updated autosave file is reduced.
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. ;-))
// Vaughan, 2010-07-30: AudacityProject::OnHistory always calls Show()
// then HistoryWindow::UpdateDisplay, so no need to do it here.
// Vaughan, 2010-10-16: Not on Windows, anyway.
// But Steve reported that on Ubuntu, View > History now crashes,
// so restore it for non-Windows.
The only call to Show for HistoryWindow is in AudacityProject::OnHistory, and it always calls HistoryWindow::UpdateDisplay. All HistoryWindow::UpdateDisplay does is check IsShown() and if so, call HistoryWindow::DoUpdate.
Removed the call to HistoryWindow::DoUpdate in the constructor because AudacityProject::OnHistory will get that done.
Removed HistoryWindow::OnShow. No reason to implement it outside the normal wxDialog::Show() mechanism, and all it did was call HistoryWindow::UpdateDisplay (and then AudacityProject::OnHistory would do that again).
Didn't see any other reasons it has been slow, as it's just getting the state names and sizes from the stack, not actually examining anything about the states. It probably doesn't really need to clear the list and repopulate it every time, but let's see if this gives sufficient improvement before adding a lot of mechanisms for tracking exactly what needs to change.
