View source for Unitary Project - issue tracking

__NOTOC__
{{intro|This page is to track the early issues with Unitary Project.
*Later we may start using Bugzilla. }}

==Contents==
#{{done}} [[#up01|UP-1 initial launch ]]
#{{done}} [[#up02|UP-2 Save Project grayed-out]]  
#{{todo}} [[#up03|UP-3 Drag&Drop]] - ''OK on Win and Linux, untested on Mac''
#{{done}} [[#up04|UP-4 more on Save Project ]]
#{{done}} [[#up05|UP-5 Amplify crashes]] 
#{{done}} [[#up06|UP-6 Save location and name ]]
#{{done}} [[#up07|UP-7 new project save name and location]] 
#{{done}} [[#up08|UP-8 last-used location not remembered ]] 
#{{done}} [[#up09|UP-9 error opening empty project]]  
#{{todo}} [[#up10|UP-10 timing tests]] - ''an ongoing activity''
#{{done}} [[#up11|UP-11 MIDI]]  
#{{todo}} [[#up12|UP-12 recent files list]] 
#{{done}} [[#up13|UP-13 Move and Rename a closed project]] &nbsp; ({{done}}) [[#up13a|UP-13a Move after Closing]] 
#{{todo}} [[#up14|UP-14 Recovery]] - ''On W10 is this just the way it is?  Fails on Mac''
#{{done}} [[#up15|UP-15 cannot update a project ]]
#{{done}} [[#up16|UP-16 Nyquist EGATs crash ]] 
#{{todo}} [[#up17|UP-17 Projects can be larger on UP-3.0.0]] - ''an ongoing activity'' 
#{{todo}} [[#up18|UP-18 Closing Audacity is slower with UP-3.0.0 ]] - ''an ongoing activity''
#{{done}} [[#up19|UP-19 Easier opening and deleting]]  
#{{todo}} [[#up20|UP-20 Aliased Projects - Bugs 2188 & 2187]] - ''works fine on Win - yet to be tested on Mac and Linux'' 
#{{done}} [[#up21|UP-21 Backup command]] 
#{{todo}} [[#up22|UP-22 Import .aup projects]] - ''wooks fine on W10 and Linux - just needs testing on Mac''
#{{done}} [[#up23|UP-23 Macro commands: Save Copy and Save Project2]] 
#{{done}} [[#up24|UP-24 Timer Record]]
#{{todo}} [[#up25|UP-25 Test disk-space exhaustion]]
#{{todo}} [[#up26|UP-26 Stress Tests]]- ''an ongoing activity''
#{{todo}} [[#up27|UP-27 Deleting, Moving renaming active project files]] - ''OK on Win, untested on Mac, fails on Linux''
#{{todo}} [[#up28|UP-28 Use of OS to create a copy project ]]
#{{todo}} [[#up29|UP-29 Save Project does not propagate project name to Audacity window]] - ''OK on Win, untested on Mac or Linux''
#{{todo}} [[#up30|UP-30 On Mac second use of Save Project as has bad name/location]]
#{{todo}} [[#up31|UP-31 X-platform compatibility of AUP3 project files]]
#{{done}} [[#up32|UP-32 Backup Projects show error on opening]]
#{{todo}} [[#up33|UP-33 History window shows misleading "space used"]]
#{{todo}} [[#up34|UP-34 Dirty Project-1 Corrupted unopenable project]]
#{{todo}} [[#up35|UP-35 Dirty Project-2 bloat retention]]
#{{todo}} [[#up36|UP-36 Failure to Save new empty project]]
#[[#up37|UP-37]]
#[[#up38|UP-38]]
#[[#up39|UP-39]]
#[[#up40|UP-40]]
#[[#up41|UP-41]]
#[[#up42|UP-42]]


<div id="up01"></div>

==UP-01 - initial launch {{done}}==
{{done}} initial launch message

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.


<div id="up02"></div>

==UP-02 - Save Project grayed-out {{done}} ==
{{done}} initial launch Save Project grayed-out on Win, Mac & Linux

This was a regression on 2.4.2 and earlier.


<div id="up03"></div>

==UP-03 - Drag&Drop {{todo}} ==
{{todo}} Drag&Drop

{{done}} 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
*{{done}} Drag&Drop of an .aup3 file onto an audacity.exe in Windows Explorer or a desktop shortcut icon for it
*{{done}} Drag&Drop of an .aup3 file onto an open Audacity Window adds that project to the open project.
*{{done}} Drag&Drop of an .aup file onto an open Audacity Window succeeds (it adds to the open project)

{{todo}} On Mac I can't drag&drop onto either the Audacity icon in the apps bar or an open Audacity project
*{{todo}} Drag&Drop of an .aup3 file onto an Audacity app in Finder or the Audacity icon in the apps bar
*{{todo}} Drag&Drop of an .aup3 file onto an open Audacity Window fails
*{{todo}} Drag&Drop of an .aup file onto an open Audacity Window - ''behavio unknown for now''

{{done}} On Linux: Steve wrote "I've tested drag & drop with simple AUP and AUP3 on Linux, and both work"




<div id="up04"></div>

==UP-04 - more on Save Project {{done}} ==
{{done}} 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.


<div id="up05"></div>

==UP-05 - Amplify crashes {{done}} ==
{{done}} Amplify works on Mac

{{done}} Amplify works on Linux

{{done}} Amplify works on W10  - and still does with Audacity 3.0.0 e7fd679




<div id="up06"></div>

==UP-06 - Save location and name {{done}} ==
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 ...

{{done}} Windows - Location offered is Documents\Audacity  and the offered name is left blank

{{done}} 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 [[#up08|UP-08]] below.

{{done}} Linux - Location offered is Documents - offered name is left blank.


<div id="up07"></div>

==UP-07 - new project save name and location {{done}} ==
{{done}} Saving a new project - odd name (based on temp file) and location (Session Data) offered

{{done}} Windows

{{done}} Mac

{{done}} Linux



<div id="up08"></div>

==UP-08 - last-used location not remembered {{done}}? ==
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.

{{done}} Windows: it's always Documents after relaunching Audacity. While Audacity remains open the last-used location is remembered, but is lost when Audacity is closed. 

{{done}} 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.

{{done}} 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. 


<div id="up09"></div>

==UP-09 - error opening empty project {{done}} ==
===Mac===
{{done}} On Mac now works with Audacity 3.0.0 51b3b0f

===Linux===
{{done}} Linux can open an empty project.

===Windows===
{{done}} works properly on W10 with Audacity 3.0.0 e7fd679


<div id="up10"></div>

==UP-10 - timing tests {{todo}} ==
{{todo}} further X-platform testing later

{{done}} 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



<div id="up11"></div>

==UP-11 - MIDI {{done}} ==
{{done}} MIDI

On both W10 and macOS Catalina I can
* import MIDI files
* play MIDI tracks


<div id="up12"></div>

==UP-12 - recent files list {{todo}} ==
{{todo}} recent files list

On Mac the Recent Files list is a bit iffy (Steve said the same about Linux)

Also seems iffy on Windows

'''Leland 07Jul20''' Temporary filenames are showing up in the file history.  Haven't looked into why as yet.

<div id="up13"></div>

==UP-13 - Move and Rename a closed project{{done}} ==
{{done}} Move and Rename

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.


<div id="up13a"></div>

==UP-13a - Move after Closing {{done}} ==

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).



<div id="up14"></div>

==UP-14 - Recovery {{todo}} ==
{{todo}} Recovery

Testing with a simulated crash.

===Windows===
{{todo}} Recovery fails - I get a new empty unnamed project opened with no offer of recovery

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.
:[[File:W10 recovered file.png|link=]]

===Mac===
{{todo}} Recovery fails - I get a new empty unnamed project opened with no offer of recovery

If I try to re-open the project I get:<br>
>Error Opening Project<br>
>Unable to parse project information.

===Linux===
{{todo}} Recovery fails:
  > Unable to parse project information.




<div id="up15"></div>

==UP-15 - cannot update a project {{done}} ==

===Windows===
{{done}} works properly with Audacity 3.0.0 e7fd679

===Mac===
{{done}} works properly with Audacity 3.0.0 e08fb5e

===Linux===
{{done}} works properly with Audacity 3.0.0 e08fb5e




<div id="up16"></div>

==UP-16 - Nyquist EGATs crash {{done}} ==
{{done}} 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

{{done}} All above the line effects, generators and analyzers work


{{done}} Linux - All effects and generators tried so far (including the above three) work correctly.



<div id="up17"></div>

==UP-17 - Projects can be larger on UP-3.0.0 {{todo}} ==
Initially Projects in UP-3.0.0 could be much larger than the equivalent project in 2.4.3
===Re-test later===
{{todo}} 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)


=== Windows ===
{{done}} testing on Audacity 3.0.0 6c2cd20 - the bloat-space is released on exit from Audacity ''(it is slow though see[[#up18|UP-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 ===
{{done}} testing on Audacity 3.0.0 6c2cd20 - the bloat-space is released on exit from Audacity ''(it is much quicker than Windows)''

=== Linux ===
{{done}} with Audacity 3.0.0 6c2cd20  - the bloat-space is released on exit from Audacity




<div id="up18"></div>

==UP-18 - Closing Audacity is slower with UP-3.0.0 {{todo}} ==

{{todo}} further X-platform testing later

===Windows===
{{done}} Testing on W10 with Audacity 3.0.0 0fbabb0 - seems fast enough to me and with a good progress dialog

===Mac===
{{done}} 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 ?

===Linux===
{{todo}} 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.



<div id="up19"></div>

==UP-19 - Easier opening and deleting {{done}} ==
{{done}} 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)''



<div id="up20"></div>

==UP-20 - Aliased Projects {{todo}} ==
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

*{{done}} [https://bugzilla.audacityteam.org/show_bug.cgi?id=2188 P1 Bug #2188] ENH: No warning is given on project opening that the project is not self-contained and relies on aliased file(s
*[https://bugzilla.audacityteam.org/show_bug.cgi?id=2187 P2 Bug #2187] - <strike>Silent crash with</strike> no error message when using a missing aliased audio file
**{{done}} Windows: works fine on W10 with Audacity 3.0.0 2accd9e
**{{todo}} Mac: still to be tested
**{{todo}} Linux: still to be tested


<div id="up21"></div>

==UP-21 - Backup command {{done}} ==
{{done}} new Backup Project 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:


<div id="up22"></div>

==UP-22 Import .aup projects {{todo}} ==
{{todo}} We need an import utility for .aup projects from Audacity 2.4.2 and earlier.

*{{done}} Windows - works properly - can be opened or imported
*{{todo}} Mac - behavior unknown
*{{done}} Linux - Steve reported by emails that this works properly

See [[#up20|'''UP-20 Aliased Projects]]



<div id="up23"></div>

==UP-23 - Macro commands {{done}} ==
*{{done}} the new backup Macro command "Save Copy" offers a file with extension .aup and not .aup3
*{{done}} 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.


<div id="up24"></div>

==UP-24 - Timer Record {{done}} ==
{{done}} Timer Record works fine.

Tested with Automatic save and Automatic Export


<div id="up25"></div>
==UP-25 - Test disk-space exhaustion {{todo}}==
{{todo}} 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.
*{{todo}} Recording
*{{todo}} Save Project
*{{todo}} File Export


'''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.

<div id="up26"></div>

==UP-26 Stress Tests {{todo}} ==
*{{done}} 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.
*{{done}} 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
*{{todo}} Projects with many, many, tracks


<div id="up27"></div>

==UP-27 Deleting, Moving renaming active project files {{todo}}==

===Windows===
{{done}} Audacity prevents Deleting, Moving or renaming active project files: .aup -wal and -shm while a project remains open

===Mac===
{{todo}} to be tested

===Linux===
{{todo}} You can delete the -wal and -shm on Linux.

{{todo}} .aup3 behavior unknown




<div id="up28"></div>

==UP-28 Use of OS to create a copy project {{todo}} ==
{{done}} Windows: use Windows Explorer to copy a project. Open it with Audacity

{{done}} Mac: use Windows Explorer to copy a project. Open it with Audacity

{{todo}} Linux: behavior unknown



<div id="up29"></div>

==UP-29 Save Project does not propagate project name to Audacity window {{todo}}==
{{todo}} Save Project does not propagate project name to Audacity window
This is a regression on 2.4.2

{{done}} Windows:  Testing on W10 with Audacity 3.0.0 2accd9e - this now works properly

{{todo}} 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.

{{todo}} Linux:  behavior unknown


<div id="up30"></div>

==UP-30 On Mac second use of Save Project As has bad name/location {{todo}}==
{{todo}} On Mac second use of Save Project as has bad name/location

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

{{todo}} Linux behavior is unknown.

{{done}} Windows - works fine


<div id="up31"></div>

==UP-31 X-platform compatibility of AUP3 project files {{todo}}==
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===
*{{todo}} Windows => Mac
*{{todo}} Windows => Linux

===Mac===
*{{todo}} Mac => Windows
*{{todo}} Mac => Linux

===Linux===
*{{todo}} Linux => Windows
*{{todo}} Linux => Mac


<div id="up32"></div>

==UP-32 Backup Projects show error on opening {{done}} ==
'''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 [https://github.com/audacity/audacity/commit/6f233cbff5e8b69f3a33b1547f5ca78af7e5499f commit 6f233cbff]
*'''Peter 13Jul20:''' Confirmed on W10 with Audacity 3.0.0 6f233cb


<div id="up33"></div>

==UP-33 History window shows misleading "space used" {{todo}} ==
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.


<div id="up34"></div>

==UP-34 Dirty Project-1 Corrupted unopenable project{{todo}}==
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


<div id="up35"></div>
==UP-35 Dirty Project-2 bloat retention{{todo}}==
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



<div id="up36"></div>

==UP-36 Failure to Save new empty project {{todo}}==
# 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

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''.


<div id="up37"></div>

==UP-37==


<div id="up38"></div>
==UP-38==


<div id="up39"></div>
==UP-39==


<div id="up40"></div>
==UP-40==


<div id="up41"></div>
==UP-41==


<div id="up42"></div>
==UP420==