... I am not sure that this will solve all problems of jittery play, but I do
think this will solve the problem of a rush of slightly late notes at start of
play.
... and hoping it is positively helpful for Linux.
In AudioIO::MidiTime(), compute one of the terms by different means.
Use PaStreamInfo::outputLatency.
Do not use the difference of PaStreamCallbackTimeInfo::outputBufferDacTime
and PaStreamCallbackTimeInfo::currentTime.
Which debugging shows is very nearly the same value for Windows and Mac.
But we suspect the PaStreamCallbackTimeInfo fields are not correctly reported
on Linux.
... though they do have a messy interaction with Undo if recording that should
be fixe.
You may get an undo history item that not only restores the gain and pan, but
removes a part of the recording.
Previously this was hard coded to use the online alphamanual.
Some other help-on-errors paths were hardcoded to use the online manual, and did not use local help even if available, so these were changed too.
Also two naming changes in the code:
ShowHelpDialog() became ShowHelp() because it typically shows the help in your browser, only showing the help in a dialog under certain circumstances.
The helpURL parameter became helpPage since it is usually a page name that is then elaborated into a url.
The Link() function became InnerLink().
Some careful http -> https changes made too.
... At least it fixes the gross problem; but there seems to be a small
accumulation of error still each time around the loop, that I don't understand
yet.
... Used to be, it became true too soon when play started after time 0, so
AudioIO::IsStreamActive() might become false too soon -- except that now there
is always a portaudio stream when there is a midi stream, so that didn't happen.
Mistake was to add mT0 to MidiTime(), which already has mT0 for its origin.
This error would affect nothing if you just let play to the end without trying
a keystroke command. The error might have been enabling the wrong commands.
Earlier fix was broken and allowed clips to overlap. Updated code:
- Checks that the modified slide amount is legal, against ALL clips, not just against later clips in the array.
- Computes tolerance correctly.
- Typically uses tolerance just once.
- Moves selection with clip
- Only restarts sliding with a 'clean slate' IF there was room on the original track.
Previously the code could reject a move to a new track, and then mistakenly allow just the horizontal part of the move on the original track(s), even with a clip blocking the way.
Fixed by giving some tolerance in how the dragged clip(s) are placed.
The tolerance is 1px, so it depends on the zoom. Therefore if zoomed in your positioning is more precise.
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.
... 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
