This removes all of the OnDemand code embedded throughout
the main codebase. Individual files related specifically
to OD have been left in place, but removed from the build.
... Require the declarations to be in .h files, to be sure graph.pl detects the
dependencies.
Only one more #include was needed in Nyquist.cpp. This doesn't reveal any
more hidden cycles.
... except Audacity.h; and in no others.
Do so even if Experimental.h gets multiply included, as in both the .h and
.cpp files.
This makes it easier to do a text scan to be sure there are no unintended quiet
changes of meaning because of omission of Experimental.h when the flag is
an enabled one.
Also move inclusions of Experimental.h earlier.
Also don't require Experimental.h to be preceded by Audacity.h to define
EXPERIMENTAL_MIDI_OUT correctly.
... for wxString and wxArrayStringEx, holding file paths (absolute or relative,
directory or plain file); to be replaced later with different types
(not yet using std::vector, becase of some uses of wxArrayString::Index with
two arguments)
... 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.
... This includes failure paths in the initialization if import. Those
resources would have been reclaimed before program exit, but not as soon as
they should have been.
... This also includes certain leaks that would happen every time a file is
successfully imported or exported. We never used avformat_free_context or
av_dict_free as we should have!
... There were also AVPacket objects repeatedly reinitialized without proper
cleanups in between. That might have leaked memory too.
I could see this on windows:
Import a file such as .aiff format, while "Files of type:"
reads "FFmpeg-compatible files".
Leave Audacity running.
Attempt to delete the file in Windows Exploerer.
Get a message from Windows that the file is in use by Audacity and cannot be
deleted.
... Should have no effect on generated code, except perhaps some slight faster
virtual function calls. Mostly useful as documentation of design intent.
Tried to mark every one of our classes that inherits from another, or is a
base for others, or has abstract virtual functions, and a few others besides.
