Fixed by putting key bindings on the left in all three views.
I also elevated EXPERIMENTAL_KEY_VIEW to no longer experimental, by excising the old code which we don't need any more.
As the translation from transifex seems not properly reflected in the release version, I decided to try updating translation manually. This is the latest translation from transfiex. I'm not good at using github. So if there is something wrong here, please take a right action for me.
Thanks.
... after I reflected more on the explanation of it in the long comment at top.
Brings back the use of PaUtil_GetTime() but now calls it also in the audio IO
callback, so we can correct the unspecified origin of times supplied to the
audio IO callback to agree with the PaUtilGetTime() clock.
Thus the Midi time calculation is again based on the clock time of the other
thread that calls MidiTime, making it a few milliseconds more accurate, while
avoiding subtraction of two times based on widely different origins, which
made the big numbers that overlowed and caused Bug1714 to happen.
I'd changed wxPanelWrapper to wxPanel in investigating bug 1664, and that change mistakenly went through in my 1664 fix.
In the Lyrics window I don't think the wxPanelWrpper's capturing of Tabs is currently necessary, but keeping it means we can add controls to Lyrics Window, and tab between them correctly on Mac, which wxPanelWrapper was introduced to solve.
Bug 299 is an review and enhance request for all error messages to show the iconic help link.
These comments may help a little with identifying where they are and aren't needed.
Problem was that on mac enable/disable clears the colour back to black.
The easiest workaround was to create a new class auStaticText that does all that we
need for wxStaticText.
Don't assume Pa_GetStreamTimePaStreamCallbackTimeInfo origin is time-of-day.
portaudio.h says you should not, and in fact it was not.
The report is that this gets us some play, but there are still freezes.
... because the sequence of update of the cache and the use of it were wrong
on Linux, resulting in wrong display when dragging tracks. Finding the
first visible track is too cheap to justify this memoizing of it.
Commit 8eb64f5f71d19a4c634cb8312fd1fa93ac75f17f was not sufficient to fix
the bug, but I think remains necessary.
It feels good to throw away this needless complication.
... Use of Destroy_ptr that was correct for 2.1.3 was no longer so after
rewrites of Screenshot tool window management, which caused crashes that were
worked-around with release(); but just use a bare pointer now.
... This little one-line fix is the right thing to do. I do not understand
deeply enough how Linux repainting events are sequenced differently from
Windows or Mac, but I understand the code history enough to know where the
bug was introduced.
Problem was that full Refresh of TrackPanel used to be done earlier, in our
handlers of custom events emitted by TrackList; but now that handling is
delayed, for good reasons, so it is correct that the UIHandle object
should request the early full refresh explicitly, not relying on TrackList
event handling.
See explanations here http://bugzilla.audacityteam.org/show_bug.cgi?id=1676#c6
The problem was that Audacity did not refill its buffers until the note-off of the last note played. That was (in the James Bond case) 2.9s after the end of the loop. The fix was to not add note off events after mT1 and instead use gAllNotesOff.
