... and also fixed analogous mistakes in some effects (Vamp, SoundTouch, and
SBSMS effects), found by review of all uses of TrackList::Channels.
The first member of the pair of iterators returned by TrackList::Channels
does not necessarily deference to a null pointer when it is incremented to
the end of the range.
... except Experimental.h, but see preceding commit.
This is especially important in the header files.
Be sure there are no quiet changes of meaning when a header file is included
in a different context, not having seen Audacity.h. Rather include Audacity.h
even if redundantly.
Also, in some header files, move more inside the include-guard #ifdef-#endif
pair.
Ran "autoreconf --force --no-recursive" for Linux build.
Add nyquist-plug-in-installer.ny to Windows build
Add Nyquist Plug-in Installer to mac build
Fix translation strings in plug-in installer
... except Audacity.h
This forces us to make each header contain all forward declarations or nested
headers that it requires, rather than depend on context.
... 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.
... so that we can use Track::SharedPointer without undefined behavior even on
tracks that don't yet belong to any TrackList.
Also fix the return type of function template TrackList::Add and remove some
casts.
... Make all line drawing go through our AColor which wraps the wxDC
line-drawing functions.
Despite what wxWidgets documentation says, the functions still don't
consistently include the first point and omit the last point of a line. I
observed inclusion of both on Mac, while on Windows, omission sometimes of the
first point instead of the last.
Discrepancies could be observed in 2.3.0 between Windows and Mac, using the
Window magnifier or command+alt+ +, zooming in closely on the ends of the
shadow lines below and right of tracks, or at the bottom-right corners of the
bevels drawn around vertical rulers.
So where there is an observable one-pixel difference of drawing between
platforms, there is the question, which was the intent when the drawing code
was written? Should the coordinates be corrected by one or not?
I reviewed each case and used my judgment.
Most of the calls are in drawing rulers. Major tick lines were drawn five
pixels long, and minor, three, on Mac. I keep this behavior, but you might
argue for making them four and two.
On the other hand the drawing of ruler grid lines, which you can see in
the equalization and frequency analysis windows, did need a one-pixel correction
to avoid straying out of bounds.
