Unitary Project - issue tracking
This page is to track the early issues with Unitary Project.
|
Contents
UP-1 initial launch
UP-2 Save Project grayed-out
UP-3 Drag&Drop - OK on Win and Linux, almost OK on Mac (bug 2437 remains)
UP-4 more on Save Project
UP-5 Amplify crashes
UP-6 Save location and name
UP-7 new project save name and location
UP-8 last-used location not remembered
UP-9 error opening empty project
UP-10 timing tests - an ongoing activity
UP-11 MIDI
UP-12 recent files list - looks OK on Win and Mac, needs testing on Linux
UP-13 Move and Rename a closed project
UP-14 Recovery - Needs retesting on all 3 platforms
UP-15 cannot update a project
UP-16 Nyquist EGATs crash
UP-17 Projects can be larger on UP-3.0.0 - an ongoing activity - This should now be corrected as vacuuming at project close has been added.
UP-18 Closing Audacity is slower with UP-3.0.0 - an ongoing activity - This should be much better now. It’s still possible that it will be somewhat slower that 2.4.2 since vacuuming may occur. But, when it doesn’t closing should be just about the same as 2.4.2.
UP-19 Easier opening and deleting
UP-20 Aliased Projects - Bugs 2188 & 2187 - works fine on Win and Mac - yet to be tested on Linux
UP-21 Backup command
UP-22 Import .aup projects
UP-23 Macro commands: Save Copy and Save Project2
UP-24 Timer Record
UP-25 Test disk-space exhaustion
UP-26 Stress Tests- an ongoing activity
UP-27 Deleting, Moving renaming active project files
UP-28 Use of OS to create a copy project - OK on Win and Mac just needs testing on linux
UP-29 Save Project does not propagate project name to Audacity window - OK on Win and Mac, untested on Linux
UP-30 On Mac second use of Save Project as has bad name/location - OK on Win and Mac - just needs testing on Linux
UP-31 X-platform compatibility of AUP3 project files
UP-32 Backup Projects show error on opening
UP-33 History window shows misleading "space used"
UP-34 Dirty Project-1 Corrupted unopenable project
UP-35 Dirty Project-2 bloat retention
UP-36 Failure to Save new empty project - OK on Win needs retesting on Mac and testing on Linux
UP-37 Crash with an empty project
UP-38 Default File Save Location
UP-39 First use of Save Project crashes Audacity and infinite recovery- UP-40
- UP-41
- UP-42
- UP-43
- UP-44
- UP-45
- UP-46
- UP-47
- UP-48
- UP-49
- UP-50
UP-01 - initial launch 
On initial launch I got a message asking if I wanted to associate .aup3 files with Audacity to click on for launch.
I never normally see such a message with any new versions. I don't get this on Mac Catalina. Leland says that this is expected behavior.
UP-02 - Save Project grayed-out 
initial launch Save Project grayed-out on Win, Mac & Linux
This was a regression on 2.4.2 and earlier.
UP-03 - Drag&Drop 
On Windows I can drag&drop an .aup3 file onto the Audacity app icon on my desktop and it launches - but I still can't drag&drop it onto an open Audacity project
Drag&Drop of an .aup3 file onto an audacity.exe in Windows Explorer or a desktop shortcut icon for it
Drag&Drop of an .aup3 file onto an open Audacity Window adds that project to the open project.
Drag&Drop of an .aup file onto an open Audacity Window succeeds (it adds to the open project)
On Mac I can't drag&drop onto either the Audacity icon in the apps bar or an open Audacity project
Drag&Drop of an .aup3 file onto an Audacity app in Finder or the Audacity icon in the apps bar
Bill 17Jul2020: This behaviour is the same as 242 on Catalina. Drag&drop an AUP or audio file onto the Dock icon or Application icon when Audacity is not running (in 242) works. Do the same when Audacity is running and it does not work. Same now in 300. So it looks like we need to address the underlying issue on Catalina. This is bug 2347.
Drag&Drop of an .aup3 file onto an open Audacity Window fails
Bill 17Jul2020: This now kind of works. Drag&drop an AUP3 into an empty Audacity window results in the project opening, but the project remains "untitled" (window title bar still reads "Audacity"). Closing the project window results in a "Save changes?" dialog. Surely this should just open the project, the same as File > Open.
Bill 18Jul2020: Testing with e669b36, drag&drop an AUP3 file onto an empty project window results in the window taking on the name of the file. Closing the window gives a "save changes" dialog. I think this is OK - any drag&drop of any file into a project window (empty or not) should be considered an import.
Drag&Drop of an .aup file onto an open Audacity Window - behaviour unknown for now
Bill 17Jul2020: Again, this kind of works. Drag&drop an AUP file into an empty project window and the AUP is imported, but the project window remains "Audacity". Seems to me the project name and window title should become the name of the AUP project that was imported. However you can drag&drop an AUP file into a non-empty project window and the AUP project will be imported into new tracks. So perhaps the project should remain untitled in these cases.
Bill 18Jul2020: As above - this works. Any drag&drop of any file into a project window (empty or not) should be considered an import.
Bill 18Jul2020: In the above two cases, on closing and accepting to save changes, the file-save dialog box has no default name. I believe 242 would offer the window title as the default save file name. Shouldn't 300 do this?
On Linux: Steve wrote "I've tested drag & drop with simple AUP and AUP3 on Linux, and both work"
UP-04 - more on Save Project 
Once the initial Save As has been made - the for subsequent saves the Save Project is no longer grayed out and I can use it to save.
UP-05 - Amplify crashes 
Amplify works on W10 - and still does with Audacity 3.0.0 e7fd679
UP-06 - Save location and name 
I imported a file with drag&drop from my desktop, when I went to Save the Project I was offered
a) a very unsuitable location "Session Data" folder - should be last used save location or default location if first ever save
b) a rather oddly constructed name ...
Windows - Location offered is Documents\Audacity and the offered name is left blank
Mac - Location offered is Documents - offered name is left blank.
BUT on Mac it's always Documents after relaunching Audacity. While Audacity remains open the last-used location is remembered, bur is lost when Audacity is closed. See UP-08 below.
Linux - Location offered is Documents - offered name is left blank.
UP-07 - new project save name and location 
Saving a new project - odd name (based on temp file) and location (Session Data) offered
UP-08 - last-used location not remembered
?
Windows: it's always \Documents\Audacity after relaunching Audacity. While Audacity remains open the last-used location is remembered, but is lost when Audacity is closed.
Mac it's always Documents after relaunching Audacity. While Audacity remains open the last-used location is remembered, but is lost when Audacity is closed.
Bill 19Jul2020:
- Start Audacity (I was using commit d2b4a0e)
- Import or generate some audio
- File > Save Project > Save Project
- Note the default location
- Save the project in a location other than the offered default location
- Close the project
- New project
- Import or generate some audio
- File > Save Project > Save Project
- Note that the default location is the one from step 4, NOT the one chosen in step 5
Shouldn't the default location be the last one used? In this situation the default location will never change from the one offered in step 4.
Note that if you save a project from 2.4.2, the default location is changed even for 3.0.0.
Is this just a simple oversight about writing to the CFG file?
Also note that for File > Import > Audio the last location used is offered as the default location for subsequent imports.
Linux - it's always Documents after relaunching Audacity. While Audacity remains open the last-used location is remembered, but is lost when Audacity is closed.
UP-09 - error opening empty project 
Mac
On Mac now works with Audacity 3.0.0 51b3b0f
Linux
Linux can open an empty project.
Windows
works properly on W10 with Audacity 3.0.0 e7fd679
UP-10 - timing tests 
further X-platform testing later
Some preliminary timing tests on W10 with Phase-1 build
UP-3.0.0 is a little slower than 2.4.2 right now 0 except for MP3 export which seems bang on the money.
Amplify takes more than double the time though.
Test file is a 3-hour stereo audio file
UP-3.0.0
- Import 3-hour WAV 1:31
- Amplify 3-hour audio 2:07
- Export 3-hour WAV 2:16
- Export as 3-hour MP3 4:36
- Import 3-hour MP3 2:07
2.4.2
- Import 3-hour WAV 0:50
- Amplify 3-hour audio 0.50
- Export 3-hour WAV 1:30
- Export as 3-hour MP3 4:35
- Import 3-hour MP3 1:12
Peter 15Jul20: I did some further timing tests on my Zurich PC today. Also an i7 256 SSD machine, but it seems faster than the HP Envy I have in Manchester for the 2.4.2 tests.
UP-3.0.0 2accd9e
- Import 3-hour WAV 0:35
- Amplify 3-hour audio 0:44
- Export 3-hour WAV 1:12
- Export as 3-hour MP3 3:37
- Import 3-hour MP3 1:03
2.4.2
- Import 3-hour WAV 0:15
- Amplify 3-hour audio 0.18
- Export 3-hour WAV 1:07
- Export as 3-hour MP3 3:40
- Import 3-hour MP3 0:45
UP-11 - MIDI 
On both W10 and macOS Catalina I can
- import MIDI files
- play MIDI tracks
UP-12 - recent files list 
On Mac the Recent Files list is a bit iffy (Steve said the same about Linux)
Leland 07Jul20 Temporary filenames are showing up in the file history. Haven't looked into why as yet.
Leland 18Jul20 I believe the file history is behaving much better now. Paul fixed the temporary filename issue.
UP-13 - Move and Rename a closed project
On W10 and mcOS Catalina I can:
- rename a .aup3 file
- move a .aup3 file to a different folder
and in both cases Audacity successfully opens it.
This is GREAT - as this is a tangle with old projects where losers could trip up and lose/damage their projects.
UP-13a - Move after Closing 
It's unclear if this is a bug or desired behaviour. It will go away if we clear the clipboard on closing a project. Paul is very very keen on keeping the clipboard around after closing the Audacity project.
Paul 07Jul20 I'm no longer very keen: I wanted to keep old behavior if it was not difficult to do safely, but now I have been persuaded that there are enough hidden difficulties.
And Paul has now fixed this. RM is fine with the tiny 'regression', that you can close a project and lose a clipboard that previously would have hung around until you close Audacity (and that caused all sorts of problems).
UP-14 - Recovery 
Leland 18Jul20: This should all be retested since many changes have been made that would have affected Recovery.
Windows
Mac
Recovery needs retesting
Bill 22Jul2020: This is fixed with commit 0c14e61
Bill 21Jul2020:
With commit 73c6225
- Start Audacity
- Get some audio into the project
- Force Quit
- Start Audacity
- You get the “Automatic Crash Recovery” dialog
- Click Recover Projects
- You get the “Project Recovered” dialog - click OK
- The project is recovered and the title bar says “Audacity”
- this looks like a typical “unsaved” project, so I should be able to do Cmd+S to save and name it - Do Cmd+S
- You do not get a Save As dialog, instead the file is saved to the SessionData folder and the title bar displays “New Project <date time> N-1”
Bill 22Jul2020: You now get a Save As dialog and the files in SessionData are deleted - Session data contains two files one of which is "New Project <date time> N-1.aup3unsaved”
- Quit - no save required
- Start Audacity
- You get the “Automatic Crash Recovery” dialog - click “Recover Projects”
Bill 22Jul2020: This is fixed - The project is recovered and the title bar says “New Project <date time> N-1”
- Quit - no save required
Linux
Peter 19Jul20: Bill tested on Mac
- Create new AUP3 project
- Create or import some audio
- Save the project
- Make several edits
- Force quit Audacity
- Open the project
- Observe: “Project Recovered” dialog
- Observe: it seems to be recovered to the state where the Force Quit was done
- Do some more edits, or not - makes no difference
- Close the project without saving changes
- Observe: note that the WAL file is deleted
- Open the project
- Observe: “Message: Failed to retrieve samples" - project is now dead
Should there be a stern warning in the recovery dialog to save the project or it will be damaged forever? Maybe we could save it for them?
The project is useless unless saved, so I say do it for them.
UP-14a - Recovery dialog should show all recoverable projects 
Use Case: user has five open projects, two are saved three are unsaved, Audacity crashes.
Peter 22Jul20: I also still have strong misgivings that in a recovery dialg after a crash the two saved projects are not listed as recoverable. If they were listed there in that recovery dialog, the recovering of all five projects and getting back (almost) to the state at crash would be simple acceptance of the recovery.
As it is with this use case the user has to get automatic recovery of there unsaved projects and then fanny around with extra clicks to open the two saved projects (I can hear dear ol' Gale complaining - "oh my poor old RSI" - and here I'm minded to agree with him).
The other reason for wanting to list all recoverable files (including saved projects) is that at Step 18 looking at the recovery dialog the poor old baffled user might think:
- "Just now I had five open projects and now only three are recoverable
- What's happened to the other two - have I lost them ?"
I foresee several anguishedForum posts from Mr./Mrs./Ms. A.Confused-User
- "What's happened to my other projects after Audacity crashed ?"
I agree that for the use case of a single open project that is saved - then it would seem reasonable to think that it is not necessary for the user to see a recovery dialog. But in the Multi-Project-Wormcan use case I outlined above it is a different matter.
So now I *strongly* think that all recoverable projects should be listed in a recovery dialog that should be shown on Audacity relaunch after a crash.
UP-15 - cannot update a project 
Windows
works properly with Audacity 3.0.0 e7fd679
Mac
works properly with Audacity 3.0.0 e08fb5e
Linux
works properly with Audacity 3.0.0 e08fb5e
UP-16 - Nyquist EGATs crash 
With Phase-2 Audacity 3.0.0 e7fd679 these all now work. I'm guessing that the fix for Amplify crashing also cured all these.
Phase-1 On Windows and Mac most shipped Nyquist effects, generators, analyzers and tools crash Audacity.
The only three that work are
- Tremolo
- Vocoder
- Rhythm track
All above the line effects, generators and analyzers work
Linux - All effects and generators tried so far (including the above three) work correctly.
UP-17 - Projects can be larger on UP-3.0.0 
Initially Projects in UP-3.0.0 could be much larger than the equivalent project in 2.4.2
Re-test later
we will need to retest later as the UP development project progresses
Projects are slightly larger as they develop on 3.0.0 than 2.4.2 - but on exiting Audacity 2.4.2 releases space whereas 3.0.0 does not. "Vacuuming" is what is needed, but when and with what trigger(s)
Leland 18Jul20: This should now be corrected as vacuuming at project close has been added.
Windows
testing on Audacity 3.0.0 6c2cd20 - the bloat-space is released on exit from Audacity (it is slow though seeUP-18)
Testing with a 5 hour mono chirp
- Audacity 3.0.0 0fbabb0 the .aup3 file occupies 3.134GB
- Audacity 2.4.2 the ,aup and data folder occupy 2.99GB
This for me is within acceptable limits
Mac
testing on Audacity 3.0.0 6c2cd20 - the bloat-space is released on exit from Audacity (it is much quicker than Windows)
Bill 18Jul2020: Testing with e669b36: 2.4.2 AUP +_data is 100 KB + 675.2 MB; 3.0.0 AUP is 680.7 MB. Bloat is removed on close.
Linux
with Audacity 3.0.0 6c2cd20 - the bloat-space is released on exit from Audacity
UP-18 - Closing Audacity is slower with UP-3.0.0 
further X-platform testing later
Leland 18Jul20: This should be much better now. It’s still possible that it will be somewhat slower that 2.4.2 since vacuuming may occur. But, when it doesn’t closing should be just about the same as 2.4.2.
Windows
Testing on W10 with Audacity 3.0.0 0fbabb0 - seems fast enough to me and with a good progress dialog
Mac
But Exit or Quit on Mac is much faster than on W10 taking a mere 3-4 seconds cf. 20-plus seconds on W10 with the same project steps.
- Is this acceptably fast for a one-hour mono project ?
retest Bill 18Jul2020: Testing with e669b36. 680 MB project, duplicate stereo track, amplify duplicated track (doubles project size), delete track, close and save. Vacuuming takes less than 2 seconds. Acceptable.
Linux
Better than before. It's still slower than 2.4.2, which was virtually instant, but nowhere near as slow as it was initially.
I've not tested this extensively, but closing a saved project seems to take a lot longer than closing an unsaved project.
UP-19 - Easier opening and deleting 
It's much easier to find projects for opening and for deleting them
I'm finding that just after a couple of days testing the UP is much easier to manage:
- Open: only one thing to look for, you don't get confused trying to "Open" the data folder
- Delete: also only one thing to look for - and on W10 at least the folders and files are always separated so tour aup could be a long way away from its data folder (which could lead to fumble-fingers trouble)
UP-20 - Aliased Projects 
It is possible that some users may still have projects that are relying on aliased files - and note that ODL has been removed from 3.0.0
P1 Bug #2188 ENH: No warning is given on project opening that the project is not self-contained and relies on aliased file(s- P2 Bug #2187 -
Silent crash withno error message when using a missing aliased audio file
Windows: works fine on W10 with Audacity 3.0.0 2accd9e
Mac: Bill 22Jul2020: With commit 7bb2417. With missing alias file, a warning is given. With alias file found it is silently copied in - is this what we want to do? In the manual perhaps note that this happens. 2.3.2 was the last version that supported alias files.
- Peter 22Jul20:I think it's fine that we silently copy in and make a consolidated project in this opaque fashion.
Linux: still to be tested
UP-21 - Backup command 
In 3.0.0 Save Compressed Copy of Project and Save Compressed Copy of Project
QA discussed the Backup Project issue and rapidly reached agreement.
1) QA likes the short form of the command File > Save Project > Backup Project
2) And QA agrees that there should be no overwrite of backup projects (or any other projects with the Backup command).
Accordingly the current error message used for the deprecated Save Lossless... and Save Compressed... can be used as-is:
UP-22 Import .aup projects 
We need an import utility for .aup projects from Audacity 2.4.2 and earlier.
Bill 22Jul2020: There was an AUP import bug that was fixed in commit 7bb2417 so this should probably be retested
This is what I found.
- In Audacity 2.4.2, import or create a stereo track with exactly 5 minutes of audio
- Save the project
- Quit 2.4.2
- Start Audacity 3 commit 0c14e61
- Open the project from step 2
- Zoom into the end and play the last 10 seconds of the track
- Observe - there is audio missing from about 4m 57.215s to the end
- The waveform is there but if you zoom in far enough the waveform disappears - not even a flatline
- If you now zoom out and select the entire track and do Repeat with 3, you will see gaps between the repeats.
Windows - works properly - can be opened or imported
- Peter 22Jul20: reteste with Audacity 3.0.0 7bb2417 - all fine, Bill's steps now work with no missing audio
Mac - Bill tested the actual importing when he worked on UP-03. The only thing he did do was the “File -> Import…” bit.
Bill 18Jul2020: Did File > Import > Audio, selected an AUP file, imported fine.
Bill 22Jul2020: tested with commit 7bb2417 - working fine.
Linux - Steve reported by emails that this works properly
Importing audio into an empty unsaved project crashes Audacity.
- AUP3 and AUP files can be imported OK into an empty unsaved project
- Audio files can be imported if other audio is first created or if the project is first saved
UP-23 - Macro commands 
the new backup Macro command "Save Copy" offers a file with extension .aup and not .aup3
the existing Macro command "Save Project2" offers a file with extension .aup and not .aup3
The new backup Macro command "Save Copy" appears to effectively be a duplicate of "Save Project2"
- Leland 07Jul20: it’s really not a duplicate (I had the feeling at first too). The difference is that once “Save Project2” writes out the new file, that file becomes the active one. With “Save Backup” the original file remains the active one.
UP-24 - Timer Record 
Tested with Automatic save and Automatic Export
UP-25 - Test disk-space exhaustion 
check that disk-space exhaustion error traps still work properly.
Paul indicates that this may have changed with SQLite 3.0.0 - so needs re-checking.
Leland 07Jul20: On Windows we get an exception loop. On Linux we get an unhandled exception. On OSX it's a bit weird. We don't get a crash, but some of the menus no longer work...like I can't Quit even though the menu item appears to be available.
UP-26 Stress Tests 
Very long projects
- Peter 14Jul20: Overnight I tested a Timed Recording of 5 hours and dis the production work to whittle it down to the required 2 hours and exported - all on Audacity 3.0.0 0fbabb0. Audio was fine - I had a label track issue that I can't now reproduce.
Simultaneous playback and recording
- James requested: Can you do some testing of play-through record please Peter? The point there is that we are both reading and writing the database, so there might possibly (low probability) be new issues around lock files. It's unlikely, but let's find out. So for worst results, play back a mix of 4 stereo channels, and record stereo and at the highest sampling rate your card offers at the same time. If we're unlucky this might get SQLite in a twist. It might try to do things in big batches and lock us out for too long.
- This worked fine on W10 with my Edirol UA-1EX
Projects with many, many, tracks
UP-27 Deleting, Moving renaming active project files 
Lelean 18Jul20: As I mentioned in some emails, there’s no real way to prevent the deleting or movement of “.aup3” or “.aup3-wal” files on Linux or OSX. Only thing you can do is give a stern warning in the manual.
make sure there is a stern warning in the Manual for Mac and Linux
Peter 20Jul20: Done seethis page on managing Audacity projects
Windows
Audacity prevents Deleting, Moving or renaming active project files: .aup -wal and -shm while a project remains open
Mac
You can delete the AUP3, -wal and -shm
Linux
You can delete the AUP3, -wal and -shm on Linux.
UP-28 Use of OS to create a copy project 
Leland 18Jul20: This should be the same on all platforms. You can copy the AUP3 file around all you like...just don't do it while Audacity has it open.
Windows: use Windows Explorer to copy a project. Open it with Audacity
Mac: use Finder to copy a project. Open it with Audacity - works OK
issue a stern warning in the Manual for: "just don't do it while Audacity has it open"
UP-29 Save Project does not propagate project name to Audacity window 
Save Project does not propagate project name to Audacity window
This is a regression on 2.4.2
Windows: Testing on W10 with Audacity 3.0.0 2accd9e - this now works properly
Mac: Testing on macOS with earlier Audacity 3.0.0 b12fafb
- If I use Save Project
- the project is saved with the correct name
- but the project name does not propagate to the top banner of the Audacity window, ir remains as "Audacity"
- If I use Save Project As - then the project name does NOT propagate to renaming the banner.
Bill 22Jul2020: commit 7bb2417 - works fine now
- New project
- Record something
- Save
- Get Save-As dialog - name the project
- Window title bar is changed to the saved name
- Save Project As
- Get Save-As dialog - name the project
- Window title bar is changed to the new saved name
UP-30 On Mac second use of Save Project As has bad name/location 
Leland 18Jul20: This seems to be working fine now.
On Mac second use of Save Project as has bad name/location
Bill 18Jul2020: With build e669b36 the second Save As offers the project name as the default file name, and defaults to the folder where the project was last saved.
On Mac when I first use Save Project As I get a blank filename offered and Documents as the location (which is good)
When I next use Save Project As a) The location offered is Session Data (this is bad) b) The project name field has: New Project 2020-07-10 11-53-11N-2.aupunsaved.aup3 - which looks like a temp filename c) Pressing Save button saves it with that rubbishy file name
Windows is not similarly affected
UP-31 X-platform compatibility of AUP3 project files 
Paul raised this issue by email.
James replied:
- We do not expect it to be cross platform at the moment. Our integers are the wrong way round.
- As RM I expect us to be revisiting the binary format and using a fixed endianness.
- It will not hurt performance.
- I also expect to use a more compact autosave format than now, but not zipped, better for recording, and to be doing that during 3.0.0.
Windows
Mac
Linux
UP-32 Backup Projects show error on opening 
Steve wrote by email: I'm frequently seeing the error message when opening a backup:
- "This project was not saved properly the last time Audacity ran.
- It has been recovered to the last snapshot."
Steps to reproduce:
- Launch Audacity
- Generate "Chirp"
- "Save Project" - name it "a"
- "Amplify"
- "Backup Project" - name it "b"
- "Undo" (undo Amplify)
- "Undo" (Undo Chirp)
- Generate "Tone"
- "Save Project" (updates "a")
- Exit Audacity
- Relaunch Audacity
- "Open" -> select project "b".
- Observe: "This project was not saved properly the last time Audacity ran. It has been recovered to the last snapshot."
Steve 13Jul20: fixed in commit 6f233cbff
- Peter 13Jul20: Confirmed on W10 with Audacity 3.0.0 6f233cb
- Bill 22Jul2020: Confirmed fixed on Mac with commit 7bb2417
UP-33 History window shows misleading "space used" 
The "Total space used" in the History window may indicate much less than the size on disk.
Steps to reproduce:
- Generate 1 hour Rhythm Track
- Save Project
- Undo
- Generate 1 second "pluck"
- Observe: The project size is over 600 MB with 1 second of audio and hardly any Undo history (only the "Pluck").
- Observe: "View menu > History" shows: "Total space used: 172.3 KB"
Proposal:
- For the History window to indicate both "total space used" and "size on disk" for the project.
- For the History window to provide an option to "compact project" (vacuum the project) to reclaim disk space.
Peter 16Jul20: Steve wrote by email:
This is looking better, but I'm not sure that compacting is working correctly.
I've been playing with a project, adding long tracks and deleting them to build up a large database, then deleting all tracks and generating a 1 second "ping".
- On saving and closing, the AUP3 file was 1.3GB.
- On "compacting" with "DB Browser for SQLite", the file size went down to 524.3 kB (524,288 bytes).
The checkbox "Compact at close" is selected.
UP-34 Dirty Project-1 Corrupted unopenable project 
Corrupted unopenable project
- Import some audio.
- Save and name the project - note file size
- Close the track.
- Generate something
- Close the project
- “Save Changes?” - No
- Observe: project is compacted - note file size has changed
- attempt to open the project
- Observe: "Message: failed to retrieve samples”
Reported by Bill on Mac, confirmed by Peter on Windows
Bill 17Jul2020: With build _1f87d4f, at step 7 the file size does not change significantly; at step 9 the project opens properly showing the audio imported in step 1.
UP-35 Dirty Project-2 bloat retention
Unremovable database bloat.
- Import some audio.
- Save and name the project - note file size
- Add new mono track
- Generate something (substantial - like 30 minutes) into it
- Close the project
- Observe: note file size has increased
- “Save Changes?” - No
- Observe: project is not compacted
- Observe: file size indicates that the samples for the generated track are stored in the file
- Open the project
- Observe: the generated track is not there, as expected
There seems to be no way to get rid of the bloat.
Reported by Bill on Mac and confirmed by Peter on W10
Bill 17Jul2020: with build 1f87d4f there is no bloat at step 9; seems fixed
later on Windows
Peter 21Jul20: Testing on W10 with Audacity 3.0.0 73c6225 However I managed to get bloat retention with testing bloat size.
- Open a 2-hour saved project: 2.49 GB
- Apply 5 effects - observe bloat groes 2.4/effect: 14.979 GB
- Save Project (no bloat removed, as expected): 14.979 GB
- Windows Explorer shows file still bloated: 14.979 GB
- Relaunch and Open project: 14.979 GB
- Save Project: 14.979 GB
- Exit - project size remains at: 14.979 GB
- Observe: massive bloat is retained
UP-36 Failure to Save new empty project 
- Launch Audacity
- File > Save Project > Save Project (or Save Project As)
- Observe: error message disk full or unwritable
- Record a little, or import audio
- Delete the new track (to empty project)
- File > Save Project > Save Project
- Observe: warning - your project is empty
- Click "Yes"
- Observe: empty project is now saved (and tests Ok on reopening)
Note that at Step 4 if you just add a new empty track, this still fails at Step 9 with the error message disk full or unwritable
Tests were on W10 with Audacity 3.0.0 6ffced4
Windows: this now works fine on Windows with Audacity 3.0.0 d2b4a0e
Mac: Bill 17Jul2020: With build 1f87d4f, no error after step 2; at step 7 get warning "Your project is now empty..."; click Yes, project is saved.
Linux: current behavior unknown - needs testing
This is a regression on earlier 3.0.0 alpha builds - but there is a possibility that this may be a Microsoft issue - as they served me with yet another security upgrade this morning.
Bill 17Jul2020: Confirmed on Mac with build c174b25
UP-37 Crash with an empty project 
Peter 20Jul20: Tested on W10 with Audacity 3.0.0 d2b4a0e
- Launch Audacity
- File > Save Project > Save Project
- Observe: crash
- Relaunch Audacity
- File > Open
- Note that the Save at step 2 produced an AUP3 file
- Open that file
- Observe: crash
Testing on W10 with Audacity 3.0.0 5652b9b - this works fine
Bill 22Jul2020: testing on Mac with commit 0c14e61 this works fine
UP-38 Default File Save Location 
Bill 20Jul2020: If the audacity.cfg contains the preference "[SaveAs]<newline>Path=/Users/<etc>" then 3.0.0 will use that as the default save-as location.
Version 2.4.2 ignores this setting and instead uses "DefaultOpenPath=/Users/<etc>" for the default save-as location.
Furthermore, version 3.0.0 does not write to this setting when using a different save-as location. The upshot is that a user of 3.0.0 will always get the location from the "[SaveAs]" setting (if they have one - apparently starting with a virgin CFG this setting will never be created).
IMO 3.0.0 should behave the same as 2.4.2 unless we decide otherwise. In any case the current behaviour of 3.0.0 is unacceptable.
There may be a bugzilla enhancement request for user preferences for default Open / Save / Export / Export Multiple paths.
UP-39 First use of Save Project crashes Audacity and infinite recovery 
Testing on W10 with Audacity 3.0.0 7e9a3f4
Using Save Project, first use of Save Project crashes Audacity.
- Launch Audacity 3.0.0 7e9a3f4
- Generate > Chirp
- Save Project
- Observe: Audacity crashes - leaves WAL and SHM files hanging around
- relaunch
- Observe: recovery dialog
- accept recovery
- Observe message "This project was not saved properly the last time Audacity ran. It has been recovered to the last snapshot."
- Observe: 30 minute chirp looks intact
- Save Project
- Observe: no crash this time
- Exit (project should be "clean")
- Observe: WAL and SHL files STILL hanging around
- relaunch
- Observe: recovery dialog again
And you can go round and round this recovery loop.
Plus, once again, when I try to use Save As or Backup I get offered "Session Data" as the location !
Bill 22Jul2020: with commit 0c14e61 this is fixed on Mac
Peter 22Jul20: Fixed with Audacity 3.0.0 7bb2417