* Fix uninitialized members of ProjectFileIO...
... which fixes this problem I observed:
Opening a previously saved project, saving-as to another path, then exiting
Audacity, gives a progress dialog waiting for checkpoints to end, which doesn't
go away
* Remove two mutexes...
... One wasn't used at all, and another was only ever used by one thread, and
then not correctly unlocked for each locking on all possible paths.
* Values that the worker thread writes and main reads should be atomic
* Remember to close db connections even after failure to open
* some comments
* No intermediate arrays (of arrays) of strings for query results...
... instead, let any query pass its own lambda to collect row data directly
however it needs to, for a bit of efficiency. Also the precautions of a new
GuardedCall
This is highly experimental. It's defers most checkpointing
to a separate thread to see if we get better throughput and
less choppiness when applying effects.
... with .aup3 projects saved earlier in 3.0.0 development, except for 32 bit
Windows builds.
Use fixed-width integer types when writing the binary format blobs, not
bool, short, int, size_t, ..., which might vary among machines and so make
.aup3 files non-portable.
Choose the widths to write whatever is narrowest among the four builds; this
makes a difference only for long and size_t which are 32 bits in the 32 bit
Windows build. (long is also 32 bits on the 64 bit Windows build.)
Also normalize the endianness to little, in case that ever matters on other
future processors.
Didn't attempt the same for the floating point types.
This reenables synchronous mode by default. However, for processing
where a power cut or crash can be tolerated, synchronous and journaling
are disabled. Once the processing is complete, they are reenabled.
Types of processing that are like this are "Save As", "Backup Project",
and "Vacuuming". They all write to a separate project file while
running, so the real project file is safe.
Unfortunately, effects are back to be slow and sluggish.
I believe I've address all of the weird file corruption issues and
I'll continue to continue testing for these.
Problem:
Playback meters do not respond during preview of non-real-time effect.
Commit ba6db6e added the meters into AudioIOStartStreamOptions.
However Effect::Preview(bool) was not modified to set the playback meter.
Fix:
In Effect::Preview(bool), use DefaultPlayOptions, which includes a playback meter.
Optimizes a couple of sample block copy loops by only preparing
the statement once outside the loop.
The connection configuration ensure that all connections use the same
settings...assuming you remember to configure it after opening. :-)
The possibly controversial setting is the "PRAGMA synchronous = off"
The "Project file size" field in the History dialog didn't work
because it didn't take the journal size into account. So, I removed
the field and improved the size calculation a bit for the sample
blocks.
This time it has the potential to produce much smaller
output files since it ONLY copies the active blocks and
not all of the blocks related to undo history. This is
done for "Save As" and "Backup Project". Normal save
can't take advantage of this, but then it really doesn't
need it as it has to depend on vacuuming.
The vacuuming at close has been adjusted to utilize CopyTo()
so it should produce similarly small files as long as the
vacuuming happens when the project is definitely closing.
This time it has the potential to produce much smaller
output files since it ONLY copies the active blocks and
not all of the blocks related to undo history.
Near as I can tell, it's pretty much done. Feeding all manner of
.aup projects will definitely need to be done. It would be best
to feed it REAL projects, not the contrived ones I've been playing
with.
... when there really is at least one new sample block committed to the table,
which is typically only once in about every six seconds, with the default rate
and sample format.
Also renamed a callback function more aptly, since blocks are not files any
more.
* Fix the reading of autosave files...
... problem was in recreating strings from buffers, but copying too many because
null terminators were lacking.
* Autosave during recording backs up all tracks correctly...
... whether to new track, or appending; and it doesn't lose the other tracks
besides the recording.
It is also unnecessary when just starting to record, so remove one call.
... Do not call Autosave (which might fail) when recovering from exceptions in
recording, but rely on the last good Autosave that happened during recording.
If dropout labels are needed, then immediately modify the undo history item, but
we can accept it if that modification fails.
Also, be sure NOT to skip Autosave in all other places that push the undo
history. Make Autosave the default unless otherwise specified.
Finally removed one unnecessary call to Autosave.
Problem:
labelStruct, a copy of the label is initialized before call to RemoveSelectedText() which acts on the real label. So when the label is updated using labelStruct, the selected text has not been removed.
Fix:
Initialize labelStruct after the call to RemoveSelectedText().
It now uses VACUUM INTO instead of the SQLite backup API
in hopes that the copies will be smaller. And VACUUM INTO
is "supposed" to be faster, but time will tell. It's easy
to put the backup API usage back in.
This also fixes a bit I missed with redoing the orphan block
handling that was reported by Paul.
And finally, it renames the AutoRecovery.cpp/.h files and AutoSaveFile
class to ProjectSerializer since the AutoSaveFile class is being
used for regular project documents now and it doesn't write to a
file anymore.
If anyone has a better idea for a name other than ProjectSerializer
feel free to change it. I hate naming things.
