Quickload

Summary
Loading large files into Audacity currently takes longer than is optimal, and makes the user wait for the summary data to be computed. The Quickload project proposes to reduce the amount of time the user needs to wait before he can begin editing audio data, by computing the summary data in a background thread that incrementally updates the display as new blocks of the soundfile are loaded. Furthermore, the concept of "loading on-demand" will allow the user to change the default loading pattern to load the parts of the soundfile he or she wishes to view immediately.


 * James Michael, IIRC one of your motivations for on-demand was that you are/were working with very large files from using ultrasonic frequencies and consequently higher than normal sampling rates. Could you say something more about this on this wiki, perhaps on your home page?

Dithered-Loading Background Thread
The summary data will be loaded in via a background thread. The thread will have a queue of blockfiles to load, which are not in linear order, but are in a maximally spread out order to provide the user with the most global representation of the file by default.


 * James Maximally spread out (e.g. load in bit-reversed sorted order) might not give the best results. That's because of disk-hunting.  It might actually be slower.  The main benefit of the design is being able to load in any order, and for loading to be delayed.  The 'order for loading' algorithm can/should be pluggable/switchable, so we have conventional left-to-right order which is still a gain because of delayed load, max-spread-out order as proposed, and order that gives priority to loading 'what is on-screen'.

Load On-Demand
When the user clicks on a particular section of the file as the background loading thread is active, the load order of the blockfiles should change to load from the point that the user has clicked on. It remains to be decided how many contiguous block files that should be loaded from that point.

Note that this also applies to when the user does sound playback. The loading thread should reorganize itself to have the blockfiles around the cursor loaded so that the user can see what is being played.

Poor-Man's Quickload
The summary data is not computed at all. Instead, when one opens a .wav file, the file selection dialog closes without presenting a file-loading progress dialog first. Summary data is not available for this track - the track artists shows 'stripy bands' to indicate this. When the user zooms in past the 256 summary data level point, sample data becomes visible.

Per-Track Progress Bar
A progress bar of some sort that displays the progress of the background loading thread. It has been discussed that this progress bar may work with the Render-on-demand batch effects suggestion, so the progress bar should be designed with this more global structure in mind.


 * James 12:37, 3 May 2008 (PDT): One decision is whether to make the 'Progress Bar' a track type in its own right, which is probably the cleanest to implement. The way I envisage it there would be square blobs on it like a normal progress bar, and in addition the background would change colour for each blockfile boundary.  Clicking on the bar should in some way show information about the blockfile.  Worth trying to get to screenshot stage very early on to show progress on coding it and to give time for discussion/feedback on the UI.

Level of Detail
Audacity currently implements level of detail loading at three levels, namely at the single sample, 256-sample, and 64k-sample levels. Data at the single-sample level is already loaded on-demand through the PCMAliasBlockFile class. Currently the 256 and 64k summary data are computed while a modal dialog spins. After the 256/64k summary data are computed they are stored into temporary block files that exist on disk. From this point on, when the display needs to fetch 256/64k summary data, it loads it on-demand from those temporary block files.