The problem was that if the user chose to quit Audacity when
the auto recovery dialog was displayed, Audacity would crash
because the command line was still parsed and any filenames
listed on the command line would still be opened. But, that
would failed because "quit" processing had already been done.
Anyway, a simple one line fix.
When building for wx3 on Linux, the backported number validators
and formatter conflicts with the wx3 version because I never
renamed them. Crashes during termination would occur because
the wx3 version and our version had different vtables.
I was thinking that we would just be able to delete the
backported version when upgrading to wx3, but since
we've made Audacity specific changes to them we can't
simply start using the real wx3 versions anymore.
Therefore, I needed to rename then to prevent the crashes.
1) Removed tabs and cleaned up consistency
2) Added removeal of "win" and "mac" directories which don't do
Linux users any good
3) Added removal of "lv2" directory as a system install of lv2
and requisites will be used instead
4) Added removal of "libvamp" directory as a system install of libvamp
will be used instead
5) Added removeal of "libsoxr" directory as a system install of libsoxr
will be used instead
6) Removed deletion of portaudio-v19/test since it seems to be required
to build now
7) Removed Windows project file updating
8) Reordered the src directory copy so that it is done before any
changes are made. This way if the tarball creation fails, you still
have a pristine src directory.
This will remove that pesky Makefile.in that would get in
the way when trying to commit. It doesn't need to be in
SVN since it is regenerated each build.
And this will restore Makefile.in.in to the unmodified
version there was a risk of losing those changes when/if
autopoint was rerun.
The changes were moved to configure.ac.
Thanks to a discussion with Steve, I went back to the docs
and found that SetCursor() is persistent. So it doesn't
have to be done in a mouse event handler. The constructor
is perfectly sufficient.
1) Shell VSTs were completely unrecognized...that is no longer the case
2) All VSTs will now ALWAYS be initialized and cleaned up from the main
GUI thread. I found that some Waves VSTs would freeze Audacity when
initialized in the audio thread and closed in the GUI thread.
3) While realtime previewing, it was possible that the wrong slave
could be used to process new blocks of audio.
4) I found that the Waves AUs don't crash on a real Mac (instead of a
virtual machine), so I removed the "black list" I'd put in just for
them. (Something to do with needing full 3D support I think.)
Anyway, #2 and #3 were quite intrusive, so as much RTP testing as possible
would be a good thing.
This will fix the clipping indicator turning on after a toolbar reset
and, as a bonus, the timers now only run if playing, capturing, or
monitoring. Will (slightly) reduce the CPU consumption.
The value in audacity.cfg is now prepended to the PATH
variable instead of appending it, so that directory
should be searched first.
It doesn't do fallback searches if the first attempt
fails.
This was my bad. I'd reset the number of capture channels
in AudioIO when the stream was stopped. Unfortunately, two
methods depended on it being valid AFTER the stream had
stopped.
Those methods, TrackPanel::OnTimer and AudacityProjecT::OnCloseWindow,
were using it as an indicator if recording had been taking place
before they stopped the stream. They then flushed the tracks, pushed
the state onto the undo stack and did some other post-recording tasks.
Turns out that the tracks are already flushed as part of the normal
AudioIO::StopStream processing, so that was redundant.
And, instead of duplicating the process, I've relocated most of each
methods processing to AudacityProject::OnAudioIOStopRecording.
