Unitary Project - issue tracking
|This page is to track the early issues with Unitary Project.
- UP-1 initial launch
- UP-2 Save Project grayed-out
- UP-3 Drag&Drop
- 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
- UP-11 MIDI
- UP-12 recent files list
- UP-13 Move and Rename
- (??) UP-13a Move after Closing
- UP-14 Recovery
- UP-15 cannot update a project
- UP-16 Nyquist EGATs crash
- UP-17 Projects can be larger on UP-3.0.0
- UP-18 Closing Audacity is slower with UP-3.0.0
- UP-19 Easier opening and deleting
- UP-20 Aliased Projects - Bugs 2188 & 2187
- 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
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.
Launched OK but when I went to Save the empty project (a practice we recommend) the Save Project was grayed-out and unavailable.
This is a regression on 2.4.2 and earlier.
Fixed on 03Jul20
I can't drag&drop a .aup3 file onto an open Audacity project window. From discussions with Leland I was expecting to be able to.
- 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 fails
- Drag&Drop of an .aup3 file onto an Audacity app in Finder or the Audacity icon in the apps bar
- Drag&Drop of an .aup3 file onto an open Audacity Window fails
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 ...
had I done that with 2.4.2 it would have offered Niamh's.aup so I was expecting Niamh's.aup3
Windows - but the offered name is left blank, which I prefer. Initial location offered is ...\Documents\Audacity, plus the previously used location is remembered and re-used on next use, as previously in earlier Audacities.
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.
This time made a short recording an went to save the project
a) I get offered a different inappropriate name - see image
with 2.4.2 this File Name field would be blank for the user to type
b) note that when I click the down arrow I get offered a duplicate of UP1.aup3
If I Save a project to a folder location while I have Audacity open and do Save As - I get offered that location
But if I close and reopen Audacity the the offered location is "Session Data" again and not the last-used location from previous use of Audacity.
On Mac opening an empty project causes an immediate crash - and the spinning beachball-of-death !
Bow works with Audacity 3.0.0 51b3b0f
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
- 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
- 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
On both W10 and macOS Catalina I can
- import MIDI files
- play MIDI tracks
On Mac the Recent Files list is a bit iffy (Steve said the same about Linux)
Also seems iffy on Windows
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.
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.
1) Generate a chirp. 2) Select a section of it and click copy. 3) Close the project 4) Agree to save it as thing.aup3. 5) WITHOUT CLOSING AUDACITY, outside Audacity find thing.aup3 in file explorer. 6) Notice that there are also mysterious thing.aup3-shm and thing.aup3-wal files kicking around. [OK, we know what they are.] 7) Cut thing.aup3 (all is hunky dory) 8) Attempt to paste it into another folder.
Observe: A: Windows Objects.
Testing with a simulated crash.
But I can successfully reopen the project and it tells me its recovered to the last snapshot.
Is this the "new form or recovery" ?
- Peter 06Jul20: I'm thinking yes it is
- Most users will realize that Audacity has crashed and can then just go and re-open their project (just as they would with Excel and Word). And for any user that just abandons a crashed project and comes back to it many months later and it will still tell 'em it's recovered to the last snapshot.
If I try to re-open the project I get:
>Error Opening Project
>Unable to parse project information.
> Unable to parse project information.
On Linux: Attempting to resave a project (to update the saved project) opens a file browser.
Continuing with the save from step to overwrite / update the project gives an assert.
Clicking "Continue" gives the error:
"Could not save project. Perhaps /home/steve/Desktop/test3-reset.aup3
is not writable or the disk is full.
so at present it is not possible to update a project.
Steve: Attempting to update a saved project leaves the project in a state that cannot be reopened. I can provide more details about this if required.
If I save to a different name the save goes ahead. But I can't reopen it. With Phase-2 Audacity 3.0.0 e7fd679 I can now open the updated project with the different name.
With Audacity 3.0.0 51b3b0f this is still not working - it appears to re-save the changed project, but doesn't ...
- I get an error when I try to open it from Recent Files, it tells me it's been removed from the Recent Files list
- If I open it with File>Open it opens with the original project, with the changes
Worse now with 51b3b0f
there is now much more serious issue with saving a modified project than reported previously For this test have a Finder Window open as well as Audacity side-by-side
1) get some audio 2) File > Save Project > Save Project as say myproject.aup3 3) Observe 3 files appear: myproject.aup3, myproject-shm and myproject-wal 4) Amplify (makes the project "dirty") 5) File > Save Project > Save Project 6) Observe: in Audacity project appears to save - no errors 7) Observe: in Finder myproject.aup3 disappears - leaving myproject-shm and myproject-wal 8) Quit Audacity
Now if the user is just in Audacity and not looking at Finder they have no idea that they've lost their project.
Plus the -shm and -wal are left around as forever detritus (what do these files do by-the-way?).
This all works properly and cleanly on W10.
Leland 06Jul20: This should now be fixed. It should have been a problem on Linux as well. Peter 06Jul20: This definitely not fixed on Mac with Audacity 3.0.0 6c2cd20
- Simpler steps to reproduce
- Launch Audacity
- Save Project
- Observe: .aup3 project file disappears - but the -wal and -shm files are left behind (and are not removed on quitting Audacity)
Phase-1 On Windows and Mac most shipped Nyquist effects, generators, analyzers and tools crash Audacity.
The only three that work are
- Rhythm track
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 06Jul20: The project file should now be about normal after the project is closed. I'll probably want to add a progress dialog.
- Peter 06Jul20: Testing on W10 with Audacity 3.0.0 6c2cd20 confirms that Audacity now releases the not-needed bloat-space on Exit. But this has reverted to being slow again see UP-18
Peter 04Jul20: Saving a project withe 3.0.0 temporarily requires double the disk space as a temporary .bak of the project is created during the save only released when the Save completes. For large projects this could be a problem.
- Leland 06Jul20: Unfortunately, I don't see a way around this. There will always be at least two copies during the save. This is the same for 2.4.2 as well, it's just not as easy to see.
testing on Audacity 3.0.0 6c2cd20 - the bloat-space is released on exit from Audacity (it is slow though seeUP-18)
A lot of journaling appears to be taking place as the project closes. And this is without "vacuuming" to release unused space see UP17.
This is very noticeable on larger projects (a one-hour mono chirp with a few effects is sufficient).
Peter 03Jul20: Leland made a fix and with Audacity 3.0.0 48287e9 closing Audacity is much quicker, almost instaneous for an already saved project.
Paul 05July20: I believe Leland's fix is not a permanent solution. It simply bypasses the deletion of unused sample blocks, that are still stored in undo states that are being abandoned when the project closes. They occupy space in the database, which is not now reclaimed (as of commit 33210ec8). I believe the proper solution will require the batching of the many deletions of blocks into a transaction. This item should be reopened.
- Peter 05July20: OK Paul so I remarked this as open again with "todo".
Tests similarly on Mac with Audacity 3.0.0 6c2cd20 with the space being properly on Exit(I can't make the second Save as that is the bug that removes the .aup3 file)
- Is this acceptably fast for a one-hour mono project ?
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)
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
- P1 Bug #2187 - Silent crash (with no error message) when using a missing aliased audio file
James wrote by email: The current bug about it still applies. There are good chances we will fix the problem for 3.0.0.
- would involve a silent copy-in. We would not need to alert the user.
- would tell the user about the error.
They would not need to go back to 2.4.2 to correct the problem. There is though the possibility that the bug stays open (unless QA raise it to P1).
Peter replied: I am thus unsure what to do about these two bugs.
As we are going to have a major d/b transition it would be good if we could fix these for 3.0.0
But I'm suspecting that by now there may be very few aliased project - so maybe it's not worth a lot of effort. I'm very undecided right now - but I'm going to log them in this UP-issues page just to keep some focus on them.
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:
As this was discussed openly on the devel mailing list and no-one else chipped-in, I think we are now good to go with this - so please (QA says) go ahead and implement this.
- 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.
Tested with Automatic save and Automatic Export
Paul indicates that this may have changed with SQLite 3.0.0 - so needs re-checking.
- Very long projects
- Multi-track projects with lots of tracks
- 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