... And label track selection code is simpler to understand, without delayed
side effects happening during drawing.
Left and right arrow keys collapse text range selection correctly
Shift-click adjusts the end of selection nearest the pick
Right (and middle) click and drag do not affect the selection
Copying empty selection has no effect on the clipboard
Left-drag behaves independently of previous selection state
... but this brings back some "mutable" members, not in LabelTrack, but in
LabelStruct.
To make that go away, and still have the Draw function const, figure out how to
update the label track layout at the right times, outside of the draw function.
Very low risk workaround implemented - close and dispose of the splash screen before creating project.
It is pretty clear it is the interaction between two dialogs during AppInit that is the root cause of the problem.
A high risk solution would involve delving into and fixing wx3 internals.
Splash screen will now disappear fractionally sooner than before - the time it takes to create an empty project.
This refers to the new Edit... command in the popup menu for individual labels.
The label editor can also be reached from toolbar menus, which shows data
for all labels.
Space required in path name. Also force old names that were set to temp directory to update to ones that aren't on Mac too.
Something to test on Mac -> What happens if suggested directory does not exist?
Untested on Mac (I don't have one). Might perhaps even fail to compile. But 1220 is a P1. Important enough for our schedule that we clear it now that I am happy enough to risk a 'blind patch'.
There is a very slight performance cost in using the sample-format set in preferences that does not seem to matter in practice. That's because the status message is updated infrequently, not every screen refresh, and the actual cost per look up is small. See http://bugzilla.audacityteam.org/show_bug.cgi?id=1436 for information on slow reading of preferences.
Fix by Uwe and Carsten of DirectSound issue (only). We can't interrogate for formats, so we use userData to tell PortAudio what the format should be. I have a 16 bit built in sound device and that continues to function correctly at 16 bit with 24 bit requested. Unable to test on a 24 bit device.
