This is needed primarily for a workaround for #7971. When importing a template
that has been exported on Ardour5 on MacOS we need to fix the paths of the
archive entries.
Later we can use this functionality also to handle imported templates if
templates with the same name already exist.
This commit only adds methods and members to FileArchive, it does not modify
anything to make regressions unlikely. This, however, leads to some duplicated
code. Eventually we should consolidate this a bit.
These changes compile okay for me (using VS2019) although they wouldn't link to my older-built libraries. Hopefully he'll be okay if he builds everything with the same compiler.
gcc, and recent clang-10 can construct new objects
using references as arguments.
However clang-8 (and MSVC?) do not:
"error: no matching function for call to 'operator new'"
The compiler apparently does not expand the template
class A <-> `A*` vs. `A const&`
for different cases.
This is a dumb stack allocator using LIFO allocation/free, with
a fallback to new/delete. This works well for small STL containers
in particular std::vector, but it's also suitable for std::map<>,
in particular copy constructing small POD maps (plugin pin mappings).
Eventually this could be combined with TLSF for a flexible
memory arena management. This is however not currently needed
for any the planned use-cases.
This code is ANSI C++98 compatible, and yet also works with
modern C++11, C++14
~StatefulDiffCommand() may trigger UndoTransaction::command_death()
which may delete the StatefulDiffCommand() that's just being destroyed.
This depends on the signal-connection order, which is undefined.
In any case when a shared_ptr<> object is being destroyed it means
that all references to it are already gone. There's no need to
emit drop_references from the d'tor.
This fixes a case when deleting a plugin, deletes all automation
undo/redo events:
<UndoTransaction name="add automation event">
<MementoCommand type-name="ARDOUR::AutomationList">
...
`delete this;` calls the d'tor which emits drop_references(),
that leads to UndoTransaction::command_death() destroying the
object, whichh causes a double free.
When a playlist is deleted and drops_references(), any
undo/redo StatefulDiffCommand referncing playlist invoke
Destructible::drop_references() of the Command.
This leads to command_death(). As opposed to UndoTransaction::clear()
the StatefulDiffCommand was not destroyed.
In case of playlists StatefulDiffCommand::_changes contains
PBD::SequenceProperty<std::list<boost::shared_ptr<Region> > >
and shared pointer reference of the playlist regions were kept
indefinitely.
This fixes the following scenario:
New session, import an file, delete the created track,
clean up unused sources (delete unused playlists)[, quit].
A reference to the imported region was kept, because of the
playlist's undo command (insert region). Yet the source file
was deleted.
PS. Most playlist changes are accompanied by GUI zoom/selection
MementoCommands. Those are currently never directly dropped.
command_death() leaves those in place.
This fixes an issue when copy/pasting plugins or aux-sends from
one track to another. After copying the processor, the state
is copied, however the Controllable state did save
the InlineControl flag, so this as lost.
(amend 93180ceea)
PBD::IgnorableControllable() is no longer used.
It also was problematic, because in every case where a
Controllable is required, min/max range and usually also
get/set value are significant.
the value is used by the parser context; the old code called it only after the *first* parser context
was created. therefore the first XMLTree::read() call has its behavior determined by libxml2's default
for this value, rather than by our explicit choice (do not treat whitespace as a note). All subequent
read() calls will use our value.
This variable inside libxml2 is actually per-thread, which just increases the stakes for calling
xmlKeepBlanksDefault() at the right time
This is similar to sort(1) --human-numeric-sort,
as opposed to naturally_less() negative numbers, hex-prefixes
and SI metric prefixes are taken into account.
This allows to indicate that a control should by default be displayed
inline in the mixer-strip.
Previously that was hard-coded for and enabled for send-level
controls only.
It's long been a guideline (and IIRC a Weff-c++ warning) that either all, or
none, of the copy methods should be defined, but this became a standard warning
in GCC9. Presumably to account for a later language change though I'm not sure
which.
I don't remember why the ChanMapping copy constructor can't just be a simple
copy (it's just a map of POD), but figure it's safer to just copy what that
does.
