| Age | Commit message (Collapse) | Author |
|---|
|
The disk-reader assumes that all playback ringbuffers are in sync
and have the same fill_level.
|
|
|
|
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.
|
|
|
|
This allows to identify Ardour thread using standard unix
tools (ps, htop) and inspect priorities, CPU load etc.
|
|
who's trying to build with MSVC2017
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.
|
|
variable
An app-level mechanism now exists in main(), via ARDOUR_DEBUG_FLAGS, and will do the same thing
|
|
|
|
Eventually this is to replace a literal name "hidden" that is
currently used as hack throughout Ardour's codebase.
|
|
|
|
|
|
|
|
Explicit functions for operator&=~ and operator|=
|
|
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)
|
|
need the Rotary flag set
|
|
|
|
|
|
|
|
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.
|
|
Mostly these are to do with TLSF which I hadn't in fact been building!! Hopefully there won't be any problems for the gcc builds.
|
|
|
|
|
|
|
|
|
|
context
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
|
|
|
|
PBD::init()
See comment for details on why
|
|
|
|
For the case at hand (plugin scale-points) it's highly unlikely to
encounter numbers > INT_MAX.
|
|
available in the GTK+ version we use for the official build stack
|
|
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.
|
|
Also address issues with MIDI and also atomicity of _pending_overwrite
|
|
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.
|
|
|
|
|
|
Second buffer is not used (or allocated) yet.
|
|
This clause is in NO_VFORK, vfork_exec_wrapper is irrelevant there
|
