... whenever they really describe the size of a buffer that fits in memory, or
of a block file (which is never now more than a megabyte and so could be fit in
memory all at once), or a part thereof.
This brings more of the code from DarkAudacity into Audacity, though not yet enabled. This will make cherry picking later easier.
- Changing colour of html displays now possible, as colour links are visible for substitution. (Can't use css as wxHTML is very limited).
- Export can now be preset to a particular format independent of preferences.
- SnapTo reversion on zoom now a DA controlled option.
- Caching of pinning preference for faster repaint because preferences are slow.
- Record Append now has sensible limit on number of tracks, rather than giving an error, and flipping the meaning of shift is now DA controlled.
Bug no longer moonphase when exporting stereo. Iterator is iterating through channels, not tracks, so we need to allow for that when we skip whole tracks.
Previously the dialog listed multiple characters that are disallowed. On Mac, only ":" is disallowed, so the text in that case can't say "any of" without looking funny.
... And in some places where a library uses signed types, assert that
the reported number is not negative.
What led me to this, is that there are many places where a size_t value for
an allocation is the product of a number of channels and some other number.
... This makes much code agnostic about how other things (functions and
arguments) are typed.
Many of these neeed to become size_t instead of sampleCount.
... 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.
... for functions in final classes.
override is like const -- it's not necessary, but it helps the compiler to
catch mistakes.
There may be some overriding functions not explicitly declared virtual and I did
not identify such cases, in which I might also add override.
... 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.
... Solution was to stack-allocate!
To make the leak happen, export with "external program" and edit the command to
"foobar" or other nonextistent program instead of lame.
