This means you can now select just a time, and get all tracks selected, or some tracks, and get all time selected.
One side effect of this is that if you select a label (only) and apply 'cut' you now just cut the label, rather than cutting all tracks. If you select a label and apply echo, you now get an error message, rather than applying echo to all tracks.
... also gathered various formatting into some routines. Should we regularize
the messages further? That is, consistently put "dB" before or after "RMS"
Also added more i18n-hint comments
Now if there is a time selection and no tracks selected, then just select all the tracks, preserving the time selection.
This helps in the case a user has made a time selection, e.g. with selection toolbar, and then clicked on track panel, losing the selection of tracks but preserving the time selection.
I also shortened some repeated cut-and-pasted code.
Fix bug in AudacityProject::AdjustForFindingStartTimes.
Bug: When there is 0 or 1 clips, q - 2 is before the begin() of the vector, and caused crash.
Fix: split the test into two tests.
When When two clips are immediately next to each other, the GetEndTime() of the first clip and the GetStartTime() of the second clip may not be exactly equal due to rounding errors. The existing code assumed they were equal, and this lead to the wrong clip boundaries or clips being found.
There are a number of ways of fixing this which could be explored. The current solution involves changing only the code for the keyboard interaction with clips.
The fix:
1. The test used for two clips being immediately next to each other is that GetEndSample() on the first clip is equal to to GetStartSample() on the second clip.
2. When searching for the start/end times of clips, the cases where GetEndTime() and GetStartTime() are not equal are taken into account. This is done in the two functions AudacityProject::AdjustForFindingStartTimes and AudacityProject::AdjustForFindingEndTimes.
... Formerly this was done correctly only for cut and delete from WaveTrack,
paste into WaveTrack, and sync-lock adjustment of WaveTrack (either lengthening
or shortening).
Now also properly done for TimeTrack cut and paste, and also for:
Split cut
Split delete
Trim
... To be very sure we can avoid roundoff errors from adding mOffset and
subtracting it again; so that evaluation exactly at a control point time gives
the exact value of that point.
The 'added space trick' to disable menu accelerators and still show them hides the accelerators completely on Linux/Mac. Linux/Mac rejects the invalid accelerators. Fortunately we don't need to disable the menu accelerators on Linux/Mac. These menu accelerators causing a problem (in bug 1637) only happens on Windows. So the 'space trick' is now used only on Windows.
Moved one ASSERT that was in the wrong place and added a new one. This might give a little more information in mac debug builds about Bug 1636 - (Mac) Equalization: Crash selecting the "RIAA" or "Telephone" curves. This is NOT a fix.
... rather than some of them being relative to the Envelope's offset.
In case of the envelopes used in TimeTrack or Equalization, offset was
always zero, so this doesn't matter, except to make the contract of the
Envelope class more explicit and sensible in isolation.
In case of InsertSpace at least, this does fix an obscure bug, which could
only happen when you have a clip, with an envelope, that starts before zero,
and you select a region overlapping that clip and some other clip, with a void
between, and you use the Join command.
Aren't you relieved that's fixed now?
It's now in recording-prefs rather than track-behavior-prefs, and to make room latency options (which are related to device) ar enow in device-prefs. Naming of new tracks has also been made slightly more compact.
This attempted fix applies the 'space' trick to make accelerators invalid, so "Left" is added as " Left" into the menus, and appears normal but does not act as an accelerator. This is now only done for the problematic accelerators rather than for all accelerators. It's believed that doing it for all accelerators caused the problem.
In debug builds users will see messages like the one below in the console:
"Unrecognized accel key ' right', accel string ignored."
This fix additionally adds 0..9 to the specially handled accelerators. This should address:
Bug 1260 - Cant type "1" in the Project Rate text box
The fix has been developed and tested on Window only. Theoretically the space might cause problems on Mac and if it does the 'space' trick could be applied just on Windows and Linux, since Mac did not seem to have the problem reported in 1260.
