Bug968 again: Fix wrong message (ctrl not shift), and omit "maximum" per Peter
Bug972, partial fix: recording in new project, record head begins at left edge
This removes the TrackInfo's slider "cache".
Originally, the cache would build to the maximum number of tracks you
had created in an Audacity session. So, if you created 128 tracks
and then reduced that to 1, you'd still have 256 sliders, 1 gain and
1 pan per track.
But, the only real thing the cache did was prevent continuous allocations
of sliders since the allocated sliders position and values wer still
being updated nearly with ever interaction since they were redrawn each
time.
In April 2010, the slider cache was changed to reduce its size by
creating a sort of ring buffer based on how many tracks were displayed
and how many tracks were in the project (I guess). Unfortunately, it
didn't really handle large number of tracks and this bug was born.
While trying to find the proper fix for this, I realized that the
cache really wasn't saving anything. Maybe a little when dragging
the thumb, but during normal track redraws and interaction, it really
didn't serve a purpose, other than use additional memory.
So, I've removed the cache and have allocated a single gain and a
single pan slider. As before, their position and value are changed
as needed when drawn and manipulated.
When it is enabled, the project can scroll up to one-half of a screenful
beyond time zero or the maximum track time. I was careful to disable selection
of negative times.
This is motivated by the smooth scrolling scrub. It behaves more sensibly at
the extremes. It can still keep the play indicator centered.
Also removed an unused member of ViewInfo.
Bug 961 - Play cursor broken after double-click scrub play
Bug 962 - Scrubbing gesture during recording places Audacity in scrubbing mode
when recording stops
As usual, I started out intending to do as little as possible
to this to get it working and wound up going overboard.
However, I believe it does allow easy management of the effects
and this will provide a basis for the full blown plugin manager
dialog.
Discovered a sizing problem when working on the effect registration
dialog and then found that others had mentioned a similar sizing
issue with the TimerRecordingDialog.
When using FloatingPointValidator and calculating the min / max
range as floats or doubles, the validated control value has been
rounded to 'n' decimal places, but the min / max range have not
been rounded. It is therefore a matter of chance whether the
rounded control value, when at the extreme limit of the range,
is within the higher precision range or not.
