Cliff reported that if you apply a macro to "Files" and you had
a "saved project" open at the time, you would get the "not saved
properly" dialog when you next open that "saved project".
This should correct it...
Several improvements in determining how much actual disk space a
sampleblock uses. This allows us to provide how much space will
be recovered when using File -> Compact Project.
In addition, the History window now provides better space estimates.
There's still the possibility if a crash happens at just the
right time that the project will be named "<project>_compact_back"
so we should probably look for it during startup.
This also changes all "Vacuum" references to "compact".
When doing a Save As, make sure autosave doc is removed
from the original project and the original project is
properly closed. (The original project does NOT get
compacted.)
The wrong sample blocks would be deleted at close in step 6:
1) New Project
2) Save and name
3) Import one stereo MP3 (about 6 minutes)
4) Save, close and re-open
5) Apply Bass and Treble to the track using real-time preview
6) Save, close and re-open
7) Message Failed to retrieve sample block
* Change usage of AutoCommitTransaction::Rollback...
... It is the more useful pattern (as in many finally blocks) for the failure
path in the destructor (which rolls back) to be the default, but an explicit
call must inform it of success.
This corrects the early return paths in Effect::DoEffect().
Throw inconsistency exception if Commit() is called again after having been
called once, successfully
Also remove a friend declaration
* UndoManager's interface uses consistent 0-based indexing of states...
... Returned by GetCurrentState() and used by SetStateTo(),
GetLongDescription(), GetShortDescription()
* SampleBlock::GetBlockID is const
* Generalized function to visit sample blocks used in a TrackList...
... Eliminating some duplication; put it in WaveTrack, not Track, to avoid
a dependency cycle.
* Eliminate more repetition with BlockSpaceUsageAccumulator
* Function to delete all blocks of/not-of a given set in one command
* DBConnection doesn't use ProjectFileIO or need friendship...
... Instead, it is given its own weak_ptr to the project
* Demote the bypass flag into DBConnection...
... So SqliteSampleBlock needs ProjectFileIO only to get the DBConnection
* Accessor functions for the connection objects for SqliteSampleBlock
* Another level of indirection to get to the DBConnection object...
... The document holds the unique_ptr to DBConnection in an attached object;
later we want the SqliteSampleBlockFactory to locate the same pointer without
using ProjectFileIO
* SqliteSampleBlock and its factory don't use class ProjectFileIO...
... Instead they share a pointer to the pointer to the current DBConnection.
This means they no longer know how to invoke the lazy opening of that
connection.
So just require that this be done before any operations on blocks happen. If
it hasn't, throw and let the application recover.
* ProjectFileIO no longer needs weak_ptr to Project for safety...
... so eliminate much ugliness from 127696879dcc5ca687ec50a4ccef7acbed563926
* Move DBConnection to new files...
... And SqliteSampleBlock does not depend on ProjectFileIO.
* SampleBlock.h doesn't need ClientData.h
* Function ProjectFileIO::Conn() isn't needed
SqliteSampleBlock now uses already prepared SQL statements for
all DB usage. This means that the statements won't have to be
compiled each time they are used.
* 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.
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.
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"
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.
* 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.
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.
* ProjectFileIO::SaveProject() won't close original db until done...
... So on the failure path, don't risk closing the original too early, failing
with the new database, and then failing to reopen the original.
Just keep the original open and a new connection open too, until it is
certain that the initial population of the new database is successful.
* Check return value from AutoSaveDelete when saving-as
* Fix the remaining unchecked sqlite3_bind* calls, which are in Autosave...
...similarly to checks in 8b3f9fa
* When saving-as or -copy, open the new database only once
* Check return value from sqlite_initialize
* Docs say: call sqlite3_close even when sqlite3_open returns error
* Be careful of possible failures of AutoSave...
... In ProjectHistory operations, do the AutoSave first and throw if there is
a failure.
Only then change UndoManager's state, confident that it remains consistent with
what was AutoSaved.
* Throw exceptions if lazy opening of project's database fails...
... because the calls to DB() as in Sqlite3SampleBlock may be in deeply nested
places that can't propagate the error codes; and besides, those functions
had been assuming non-null returns from DB(), which might have crashed before,
but now the assumption is correct when the throw didn't happen.
Note that this exception may also happen during attempted Autosave. Uses of
Autosave were reviewed and some changes made in the previous commit.
* Define SampleBlockFactory replacing static members of SampleBlock...
... This will become an abstract base class
* Sequence and WaveTrack only store SampleBlockFactory not Project...
... This adds a dependency from Track to SampleBlock which temporarily enlarges
a cycle in the dependency graph
* Register a global factory of SampleBlockFactory...
... so that later we can make an abstract SampleBlockFactory, separate from the
concrete implementation in terms of sqlite, and inject the dependency at startup
avoiding static dependency
* New concrete classes SqliteSampleBlock, SqliteSampleBlockFactory...
... separated from abstract base classes and put into a new source file,
breaking dependency cycles, and perhaps allowing easy reimplementation for other
databases in the future.
Note that the new file is a header-less plug-in! Nothing depends on it. It
uses static initialization to influence the program's behavior.
* Compile dependency on sqlite3.h limited to just two .cpp files...
... these are ProjectFileIO.cpp and SqliteSampleBlock.cpp.
But there is still close cooperation of ProjectFileIO and SqliteSampleBlock.cpp.
This suggests that these files ought to be merged, and perhaps ProjectFileIO
also needs to be split into abstract and concrete classes, and there should be
another injection of a factory function at startup. That will make the choice
of database implementation even more modular.
Also removed one unnecessary inclusion of ProjectFileIO.h
* Fix crashes cutting and pasting cross-project...
... in case the source project is closed before the paste happens.
This caused destruction of the ProjectFileIO object and a closing of the sqlite
database with the sample data in it, leaving dangling references in the
SqliteSampleBlock objects.
The fix is that the SqliteSampleBlockFactory object holds a shared_ptr to the
ProjectFileIO object. So the clipboard may own WaveTracks, which own WaveClips,
which own Sequences, which own SqliteSampleBlockFactories, which keep the
ProjectFileIO and the database connection alive until the clipboard is cleared.
The consequence of the fix is delayed closing of the entire database associated
with the source project.
If the source project is reopened before the clipboard is cleared, will there
be correct concurrent access to the same persistent store? My preliminary
trials suggest this is so (reopening a saved project, deleting from it, closing
it again -- the clipboard contents are still unchanged and available).
* Eliminate unneeded back-pointer to project from non-wave Tracks...
... now that DirManager is gone
* Remove unused declarations
* SampleData::mProject was not used
* Correct ProjectFileIO::GetLibraryError
* Remove unnecessary #include directives
These mainly address the bugs that Steve reported and a couple
more I found along the way.
Corrected ProjectFileIO::GetMinMaxRMS() - It was still using the
original method of keep all block data in memory. I missed it
when I redid everything. Fixes his Amplify crash.
Temporary filenames should no longer be shown to the user.
Resaves will no longer present a Save As dialog.
Cleaned up duplicate pathname handling in ProjectFileIO.
Returned proper errors when loading a project
!!! THERE WILL NO DOUBT BE BUGS !!!
This is a big one and there's still several things to
complete. Just want to get this in the wild to start
receiving feedback.
One big thing right now is that it will NOT load pre-aup3
files. An importer is on the way for that.
... Reimplemented without making dependency cycles.
Project and ProjectFileManager publish events for change of active project or
change of a project title.
WindowMenus.cpp can listen for those events, so that it can update the menu
appropriately. So it's all done nonintrusively in the rest of the code.
These changes were made too close to release and are considered too dangerous for 2.4.0.
We will use the changes Leland provided. We can review these proposed changes by Paul after 2.4.0 is released.
... Reimplemented without making dependency cycles.
Project and ProjectFileManager publish events for change of active project or
change of a project title.
WindowMenus.cpp can listen for those events, so that it can update the menu
appropriately. So it's all done nonintrusively in the rest of the code.
