... 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.
... Reopens minor bug 543 as a won't-fix.
Bring back the shell script as a way to change environment for Audacity before
it starts.
Perhaps this fixes Bug 1703 too: double-click on .aup before Audacity starts
brings up an empty window.
... That is, put a little shell script in the application bundle, and invoke
it (in Release, though not Debug where it interferes with Xcode debugging)
See commit 07661c186f7e8e6d978fa35485d65364b96dfb3a
The shell nulls the environment variable DYLD_LIBRARY_PATH and then executes
the main program.
This is needed because changes to DYLD_LIBRARY_PATH during the main program's
run fail to affect the loading of dynamic libraries afterward.
We need null in DYLD_LIBRARY_PATH to make absolute paths to libraries take
priority.
More info:
Documentation of workings of the macOS dynamic loader
https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html
The same problem and solution is discussed here
https://stackoverflow.com/questions/6713692/problems-with-using-setenv-and-then-making-the-dlopen-call
It is claimed there that Firefox did the same trick with a shell, which I do
not observe in my version, but GIMP 2.8.16 does this, as I can see by examining
package contents
Also note the mention in this commit's comments (where the script was removed
because bug543's fix left it unused), that the script also used to
interfere with signing. I hope that there will be a way around that.
98186b9317adf842e0469fe98175b55da31d3210
This at once reverts fixes for bugs 543 and 290;
290 being a problem loading libraries,
543 being a minor problem with the fix for 290, resulting in a rewrite of the
fix, but this rewrite having bad consequences, as in bugs 1567 and 1703.
See discussion in bug 1702 for the detailed history
See also commits
a05d039055909d7d1dc2d4f31e1fe0659a3207dd (fork and crash)
36361a6b86dac4b0f2b16b7017007b4cc7717c7a (introduced execve)
... This conservative fix depends on where you put the executable bundle.
Assuing the executable is in /Applications, and the other Audacity version
(past or future) is there too (either bundled as for 2.1.3 and later, or
in a folder as for 2.1.2 and previous):
The .ny files that are part of the other version's shipment are ignored, and
therefore the Effects menu avoids duplicates.
But the .cfg file is not rewritten to eliminate them, in case you want to
switch back to the other version. If that other version is 2.1.3 or earlier,
sorry but you will see duplicates.
Fix off by one error in size.
Git-bisect indicated a problem (on Mac only) caused by a change in an image file.
It's possible that this is an error in code that we have 'got away with' until now.
We always have an extra zero on the end of the image data and included it in the count of the
size of stream to unpack. For a particular image this may have triggered a memory corruption
problem.
