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.
Adding an orange border around the images in a theme makes it much easier to cut and paste in the correct position. I've also expanded the internal images and fixed up a few image details - the pins/bobbins on darker themes, and the light blue rather than dark blue for negative times.
This progresses this bug. Specifically on Windows, Left and Right arrows and Enter (non keypad version) should now no longer be a problem. The fix is to not show these shortcuts in menus, because otherwise the menus will catch the events. Unfortunately attempts to show these specific shortcuts in the menus bring back the bug.
Steps to reproduce for 1637 will need to be updated.
The image cache that users work with should now have 'pixels' that are 4x4. This will in time allow us to have large or small versions of all buttons, and also means we have hi resolution images for HiDPI screens. The actual cost of the extra size should be small, as compression will see lots of repetition.
The main point of doing this now is so that new contributed themes can be HiDPI from the start.
The time ruler previously used blue for negative numbers, when scrolling left of zero was enabled. This was broken by adding the dark-theme code. Fixed now, and with a new configurable colour for it which defaults to blue if non provided.
As mentioned by PRL
(https://sourceforge.net/p/audacity/mailman/message/35763043/),
WarpAndTransposeNotes didn't transpose, but _did_ wrap, notes that were on
channels that were hidden. This behavior is inconsistent with all other
operations, and thus has been changed to always transform and wrap
regardless of visibility.
Additionally, fix the UI portions of these, and fix Trim for note tracks
(the code already existed, but due to flags would not work). As PRL
requested, this is gated only behind USE_MIDI.
It's no longer used, and the new set up for MixerTrackCluster makes them
unable to change the type of the slider (so it should also no longer need
to be used).
This reintroduces the buttons to toggle display of individual midi
channels, and cleans up the code behind that feature.
This functionality has actually been present in production versions of
audacity for a while, at least for clicking. However, the buttons
themselves were not drawn, making it exteremly painful (but possible) to
use.
As requested by PRL, this is always enabled if USE_MIDI is defined.
