... with run-time assertions.
I examined each place and reasoned that the narrowing was safe, and commented
why so.
Again, there are places where the sampleCount variable will later be changed
to have a different type, and they are not changed here.
... A non-narrowing conversion out to long long is a necessity, but the
conversions to float and double are simply conveniences.
Conversion from floating is explicit, to avoid unintended consequences with
arithmetic operators, when later sampleCount ceases to be an alias for an
integral type.
Some conversions are not made explicit, where I expect to change the type of
the variable later to have mere size_t width.
... 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.
... I believe this list of four places is exhaustive.
There are many, many more safe narrowings that I examined.
This resulted from changing the definition of sampleCount in my builds so that
narrowing conversions failed to compile without some fixes, and I examined and
fixed every place.
The rest of that work is not yet shared.
Introduce *DECIMAL-SEPARATOR* global for Nyquist.
Improvements to numeric validation error messages.
Fix *TRACK* START-TIME and END-TIME properties for tracks with different
length channels.
Update Adjustable Fade, Regular Interval Labels and Vocal Removal
to use numeric text inputs.
This does NOT fix bug 1020.
This can improve progress count for Nyquist effects
that do not process all of selection (bug 558) and provides some
protection against 2^31 overflow issues (bug 439).
... Also removed one line from the track control drop-down, and changed
accelerators to more mnemonic choices.
Also the open page of View Settings... determines track view type after OK
... not per track,
and the preferences or View Settings page has a separate static box for
global settings as opposed to track settings. This is the only global setting
for now.
... SpectrogramSettings does that instead, and Preferences or View Settings
are the user interface for changing it.
Handle invalidation of spectrogram pixel cache for scale type changes,
just as for other changes of settings. No more
TrackArtist::InvalidateSpectrumCache().
View type of track now switches to Spectrum when applying or OKing the
View Settings... dialog and the Spectrogram page is open (and for now
it is still the only page)
... by passing invalid frequency values,
rather than by checking the 'view property in each effect.
Spectral editing is now permitted only for appropriate track view types.
But I would suggest reconsideration of the exact conditions in which we do
this.
As this is a reversal of change committed in 2007 with no real
explanation or history behind that change other than it was
done for Export, we should probably give exporting a bit of a
workout.
