Cairo::curve_to renders cubic Bézier splines, those are not
generally useful in a DAW context.
Canvas::Curve implements centripetal catmull-rom spline drawing
which can be used for fades and automation interpolation.
This adds a basic support to use multiple sound-cards, currently
limited to two devices: In/Out with shared settings.
Advanced setups still have to resort to using the ARDOUR_ALSA_EXT
environment variable
This apparently happens on some Windows systems when exporting
a range starting at 00:00:00:00
I'm still hoping there's a better fix for these race-condition
issues, perhaps by kicking the TFSM...
When running from the src-tree, ardev_common.sh sets multiple
data-paths, to allow running ./ardev ./gtk2_ardour/ardev.
Pick the first one that contains a "web_surfaces" subfolder as
docroot.
This picks up where cfd95340b1 left off.
The goal is to ensure that the butler has completed all
PostTransportStop related tasks and won't meddle with transport
after exporting has started.
Previously this could happen, because realtime_stop() queues
PostTransportStop and the butler is sommoned after every
export process cycle.
Since 61e7f3176b the butler keeps calling non_realtime_stop()
every time it is woken up, until TFSM comes around and unsets the
flag in the process callback.
This cuts reverb tails and synth sounds after export.
Disabling freewheeling, continues normal processing where
export left off. This previously kept notes ringing, or reverbs
audible.
The actual issue was introduced in 61e7f3176b:
Session::non_realtime_stop() no longer unsets PostTransportStop
(other changes from that commit are not relevant).
The real issue however is a race-condition.
So far this only seems to happen on MacOS, Coreaudio.
It seems that non_realtime_stop() is called in the butler-thread
after exporting has started, even though the butler has been
paused in wait_until_finished().
Perhaps Coreaudio thread switches causes TransportFSM to
reinitialize and scheduling the butler?
The use of `usleep()` makes this rather a workaround.
However it's sufficient for the coreaudio rt thread to run
at least once.
Port (or Tracks) can be safely added during playback, however
the disk-reader's playback buffer is initially empty. This lead to
false-positive Underrun() signals when processing takes place
before or concurrently with re-filling the disk-buffer for the new
channels.
Now new empty buffers are ignored, and produce silence until the
initial refill is complete. There is however no per-channel
de-click in, yet.
This fixes: play some audio track, ctrl+drag a region to the
drop-zone, creating a new track while playing.
Main features: Plugin (Select & Edit)
1. Plugin Select: When a track is selected that has PluginInserts, pushing the "Plug-In" button on a mackie will list these across the strips. Clicking a vpot of a strip enables editing the parameters of this selected plugin.
2. Plugin Edit: When a Plugin is selected for editing, the input parameters of the plugin are shown across the channel strips and the vpot is assigned the corresponsing AutomationControl for the parameter.
Minor features
- When the number of plugins or the number of parameters exceeds the number of strips available on the surface, one can flip through "pages" of views using the Cursor Left and Right keys (this logic I took from http://www.emagic.de/media/support/content/manuals/LogicControl_en.pdf)
- When in the Plugin Select mode, rearranging the plugins in the mixer strip is reflected on the surface.
- When in Plugin Edit mode, rearranging the plugins in the mixer strip still retains the edit view of the selected plugin (rearranging does not take away the current subview)
- When removing a plugin in the mixer strip, this is reflected in Plugin Select, while the view jumps to Pan/Surround (the None subview) when in Plugin Edit mode.
- Removing a track resets the subview to None
- When in a Subview that is track-specific (Track, EQ, Send, Plug-In, Inst), selecting a different track retains the subview but updates the channel displays and vpot assignments accordingly. When in Plugin Edit mode for track A, and track B is selected, it changes to Plugin Select mode for track B (if plugins are present).
Only compare playback latency, delaylines in tracks do not
push back the capture latency to the source.
The delayline on tracks sits in between disk-writer and disk-reader,
delaying input to align with the disk-reader.
Furthermore tracks may be connected to different inputs,
even though those inputs are usually from the same hardware
device, capture latency of those ports can differ.
Ardour5 route templates seem not to have a in the root node playlist
property. Ardour generally relies on that Track::playlist() always returns a
valid playlist. Thus we need to create a playlist even if we don't have a
playlist property in the route template's root node.
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.
Auto-connect is handled in a background thread, so newly created
tracks are not immediately connected.
This causes a race-condition when fan-out directly disconnects
and re-connects ports after track/bus creation.
Track name is implicit, so instead of "meter-<name>", showing a
translatable label "Meter" is sufficient and consistent with "Fader".
Under the hood, for introspection, the processor name remains as is.
This is intended to prevent crashes when unregister_port() modifies the contents of these
two members at the same time that something else is iterating over them.
This exposes custom plugin model/mode. It can be useful for
the GUI to detect if effective settings have changed, and
context-menus have to be re-build.
This reverts commit fac8d84786.
This fixes fan-out. The track should be created before any tracks or
busses are created that are fed by the MIDI track.
The apparent motivation for fac8d847 was MIDNAM related
(there was code in the GUI that needed the instrument, which was
called from within ::add_routes).
This should no longer be the case, the GUI needs to pick up
instrument changes after track creation via processors changed;
besides MIDI busses were still created before the instrument.
* Signals use camelcase.
* use a static signal, independent of the route
Previously the signal was handled by RouteUI, which
caused various issues:
* the RouteUI may not yet be available
* There may be many RouteUIs for a single Route
(mixer, editor-mixer, meter-bridge strips)
This reverts 05c77db773 (revert necessary due to 4637c49838)
Since 4637c49838 we no longer emit Located() in ::backend_sync_callback().
Therefore we must emit Located() in ::locate() even if we are
synced_to_engine().
Otherwise the playhead is not updated when synced_to_engine() in some
circumstances.
When we create a new session and are using a template from an old version of
Ardour, we should not issue the VersionMismatch dialog and not make a copy of
the session file for the old version.
We need to extend the signature of Session::load_state() to tell it if we are
creating a session from a template. Session::_is_new cannot be used for it
because it has a the semantics if to auto connect the the master bus.
* Remove unused direct calls into plugin
* Assume empty model to mean plugin-provided MIDNAM (!)
The route owned Instrument-Info is the central access point used
by the GUI for MIDI name lookups.
At this point in time, custom settings are saved/restored by the
GUI (MidiTimeAxisView). InstrumentInfo provides a volatile store
for MIDNAM mode and model.
If the last read was not looped, but the new one should be, we need to ignore the heuristic. Ditto for vice-versa.
This isomorphic with the read-reversed case
This fixes another assert(), caused by configuring processors,
before set_processor_state() was called.
Route::configure_processors() will be called later.
---
#3 0x00007ffff2472102 in __GI___assert_fail at assert.c:101
#4 0x00007ffff7a8ca1f in ARDOUR::Route::setup_invisible_processors() at ../libs/ardour/route.cc:5013
#5 0x00007ffff7a7a665 in ARDOUR::Route::configure_processors_unlocked at ../libs/ardour/route.cc:1870
#6 0x00007ffff7a79377 in ARDOUR::Route::configure_processors at ../libs/ardour/route.cc:1719
#7 0x00007ffff7a902c0 in ARDOUR::Route::set_disk_io_point at ../libs/ardour/route.cc:6041
#8 0x00007ffff7a7ea0a in ARDOUR::Route::set_state at ../libs/ardour/route.cc:2679
When limiting the message count (e.g. for display in a dialog),
use reverse order, and only print errors.
When loading a session fails, the most recent error is
more likely the real cause.
Previously set_state() -> set_meter_point() acquired the
process-lock to change meter-position, usually causing x-runs
when setting route-state.
This also fixes an issue introduced in fd414ec158. After
populating the processor list, force setting the meter-position
looks up the output streams of the processor before the meter.
However the processors are not configured. That will only happen
later from Session::post_engine_init().
---
#3 0x00007ff07b7d4102 in __GI___assert_fail at assert.c:101
#4 0x00007ff080d3224a in ARDOUR::PluginInsert::output_streams() const at ../libs/ardour/plugin_insert.cc:289
#5 0x00007ff080de8c30 in ARDOUR::Route::set_meter_point_unlocked() at ../libs/ardour/route.cc:4106
#6 0x00007ff080de8699 in ARDOUR::Route::set_meter_point(ARDOUR::MeterPoint, bool) at ../libs/ardour/route.cc:4037
#7 0x00007ff080ddfad3 in ARDOUR::Route::set_state(XMLNode const&, int) at ../libs/ardour/route.cc:269
This fixes the following issue:
On the master channel insert the waveform scope before the fader.
Then set the meter position to custom and move the meter to the
very beginning of the chain.
Before this change, when set_meter_point() was called the
processor list only contained the Fader (_amp) and no other
processor. _main_outs was not yet present in the list, and
Route::maybe_note_meter_position() triggered an
and assert(_processor_after_last_custom_meter.lock());
See also d0dca7daf0
This can help when running with very low latency and the
initial process callback is [indirectly] expensive.
E.g. load a heavy session the a RPi4, initial setup can pull
in a lot of data, which blocks the bus.
In particular with the ALSA backend this can lead to poll timeout
which effectively stops the backend.
This allows for caches to warm up, background worker threads to
spin up and things settle down. This also prevents initial
audible artifacts of live input.
In almost all cases this completes before the GUI is brought up.
When recover() successfully re-initializes the device,
processing can continue just like after an x-run.
This can happen during initial session load of "expensive"
sessions (in particular on slow systems, e.g. Raspberry Pi)
usually with synths. Worker thread pulls in many external
files in the background which blocks the bus for a long time.
resulting in a poll-timeout.
This fixes a deadlock when closing the session.
Session::destroy() takes the engine-lock while removing
unhandled session-events. In [1], the event-queue held a last
reference to a Track, and releasing that object triggered
events (here ~IO) that required the lock.
---
[1]
#2 0x0041743a in Glib::Threads::Mutex::Lock::Lock at /home/ardour/linux-armhf/stack/include/glibmm-2.4/glibmm/threads.h:643
#3 0xb67433ba in ARDOUR::IO::~IO at ../libs/ardour/io.cc:105
#4 0xb6743612 in ARDOUR::IO::~IO at ../libs/ardour/io.cc:111
#5 0xb6758e66 in boost::checked_delete<ARDOUR::IO> at /home/ardour/linux-armhf/stack/include/boost/core/checked_delete.hpp:34
#6 0xb675912c in boost::detail::sp_counted_impl_p<ARDOUR::IO>::dispose at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/sp_counted_impl.hpp:92
#7 0x004178d8 in boost::detail::sp_counted_base::release at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/sp_counted_base_sync.hpp:129
#8 0x00417986 in boost::detail::shared_count::~shared_count at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/shared_count.hpp:426
#9 0xb662343a in boost::shared_ptr<ARDOUR::IO>::~shared_ptr at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/shared_ptr.hpp:341
#10 0xb6a4af7a in ARDOUR::Route::~Route at ../libs/ardour/route.cc:282
#11 0xb6b9404c in ARDOUR::Track::~Track at ../libs/ardour/track.cc:71
#12 0xb697164a in ARDOUR::MidiTrack::~MidiTrack at ../libs/ardour/midi_track.cc:94
#13 0xb697177a in ARDOUR::MidiTrack::~MidiTrack at ../libs/ardour/midi_track.cc:96
#14 0xb6ac525a in boost::checked_delete<ARDOUR::MidiTrack> at /home/ardour/linux-armhf/stack/include/boost/core/checked_delete.hpp:34
#15 0xb6acde00 in boost::detail::sp_counted_impl_p<ARDOUR::MidiTrack>::dispose at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/sp_counted_impl.hpp:92
#16 0x004178d8 in boost::detail::sp_counted_base::release at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/sp_counted_base_sync.hpp:129
#17 0x00417986 in boost::detail::shared_count::~shared_count at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/detail/shared_count.hpp:426
#18 0xb664dca6 in boost::shared_ptr<ARDOUR::Track>::~shared_ptr at /home/ardour/linux-armhf/stack/include/boost/smart_ptr/shared_ptr.hpp:341
#19 0xb6aaf67e in ARDOUR::SessionEvent::~SessionEvent at ../libs/ardour/ardour/session_event.h:42
#20 0xb6a91a88 in ARDOUR::Session::destroy at ../libs/ardour/session.cc:753
#21 0xb6a8fb20 in ARDOUR::Session::~Session at ../libs/ardour/session.cc:460
#22 0xb6a9075e in ARDOUR::Session::~Session at ../libs/ardour/session.cc:46
This fixes a crash with missing [MIDI] write-sources after
duplicating tracks [1]: Stealing write-source name fails, because
there is no write-source.
When duplicating tracks, reset_write_sources() is called before
any playlists are set [2]. So no new write-sources are created
because _playlists[DATA-TYPE] is empty.
During normal track creation write-sources are usually added
by the input-change handler [3]. However in this case the
state has been set, and since there is no change,
DiskWriter::configure_io does not call use_new_write_source()
NB. This also re-creates write-source when playlists are changed.
-=-
[1]
#3 0x00007f4420690102 in __GI___assert_fail at assert.c:101
#4 0x0000562bfa300dc9 in boost::shared_ptr<ARDOUR::SMFSource>::operator->() const at /usr/include/boost/smart_ptr/shared_ptr.hpp:734
#5 0x00007f442579ffa1 in ARDOUR::DiskWriter::steal_write_source_name[abi:cxx11]() at ../libs/ardour/disk_writer.cc:1290
#6 0x00007f4425e476b6 in ARDOUR::Track::steal_write_source_name[abi:cxx11]() at ../libs/ardour/track.cc:476
#7 0x00007f4425d060a2 in ARDOUR::Session::create_midi_source_by_stealing_name at ../libs/ardour/session.cc:4955
#8 0x0000562bf9ed39ab in MidiTimeAxisView::add_region at ../gtk2_ardour/midi_time_axis.cc:1650
#9 0x0000562bf9b05f2a in Drag::add_midi_region at ../gtk2_ardour/editor_drag.cc:568
-=-
[2]
#0 0x00007ffff7582e2f in ARDOUR::DiskWriter::reset_write_sources at ../libs/ardour/disk_writer.cc:946
#1 0x00007ffff757fce6 in ARDOUR::DiskWriter::set_state at ../libs/ardour/disk_writer.cc:333
#2 0x00007ffff7a81c93 in ARDOUR::Route::set_processor_state at ../libs/ardour/route.cc:3054
#3 0x00007ffff7a7f5d5 in ARDOUR::Route::set_state at ../libs/ardour/route.cc:2697
#4 0x00007ffff7c2aa1d in ARDOUR::Track::set_state at ../libs/ardour/track.cc:172
#5 0x00007ffff794f204 in ARDOUR::MidiTrack::set_state at ../libs/ardour/midi_track.cc:152
#6 0x00007ffff7b7e06b in ARDOUR::Session::XMLRouteFactory at ../libs/ardour/session_state.cc:1890
#7 0x00007ffff7addf7e in ARDOUR::Session::new_route_from_template at ../libs/ardour/session.cc:3048
#8 0x000055555621329a in DuplicateRouteDialog::on_response(int) at ../gtk2_ardour/duplicate_routes_dialog.cc:194
-=-
[3]
#0 0x00007ffff7583243 in ARDOUR::DiskWriter::use_new_write_source at ../libs/ardour/disk_writer.cc:996
#1 0x00007ffff75831c7 in ARDOUR::DiskWriter::reset_write_sources at ../libs/ardour/disk_writer.cc:989
#2 0x00007ffff75851ea in ARDOUR::DiskWriter::configure_io at ../libs/ardour/disk_writer.cc:1335
#3 0x00007ffff7a7b308 in ARDOUR::Route::configure_processors_unlocked at ../libs/ardour/route.cc:1912
#4 0x00007ffff7a79e4b in ARDOUR::Route::configure_processors at ../libs/ardour/route.cc:1719
#5 0x00007ffff7a86695 in ARDOUR::Route::input_change_handler at ../libs/ardour/route.cc:3632
Completing readout available() returns 0, until all
background threads have finished and joined.
This also improves performance by feeding suggested/required
amount of samples on every process() call.
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.
Note that this is done at the GUI level, might need to double check if there are
other paths into a "save" that should be covered. Control surfaces use the action, but
Lua comes to mind
On recent Mac systems (Catalina) OpenGL is slower compared to
directly using GTK's NSView. Furthermore when compiled on
Catalina, and running on a system with a Retina screen, the initial
size of the canvas may be wrong:
libs/gtkmm2ext/nsglview.mm:175:1: warning: method possibly
missing a [super reshape] call [-Wobjc-missing-super-calls]
This is not an issue when running versions compiled on older systems.
removal of tape tracks removed an intermediate argument in the argument list; presence of default args for the
last two arguments and implicit conversion from int->bool prevented the compiler from complaining
about any existing calls.
This supplements/extends a54b000a70
Substantive comments associated with code in Session::plan_master_strategy.
Known not to work for reverse TC. Also, the JACK related code has not yet been tested
The stereo-width panner is not generally useful. In order to
change the azimuth, width has to be reduced, which usually leads
to comb-filter artifacts.
Equal power stereo, also matches the default mono to stereo panner
better than the stereo-width panner.
Last but not least, control surfaces only have an azimuth control
knob, without an easy way to reduce width, this leaves
the panner insensitive.
Direct call to Session::cleanup_sources() from ARDOUR_UI::cleanup()
didn't zero initialize size. This centralizes initialization,
so cleanup_trash_sources() does not need to explicitly clear it.
Previously when loading Ardour v2, v3-5 sessions, tracks were
created with a dummy name "toBeResetFroXML".
In v6, Track::init() creates a playlist when the track name is
not empty. Later Track::set_state() calls set_name(). When a
playlist exists, the playlist's name is set to match the track's name.
When loading v6 sessions none of this happens. A previously loaded
playlist will be assigned by ID.
Older versions identified Playlists by name and by the time the
playlist is assigned, there may be ambiguities. With the default
(track-name = playlist-name) two playlists with the same name exist:
(1) the playlist loaded from the session file
(2) the playlist created by Track::init()
Playlists are stored in an ordered std::set<shared_ptr<Playlist>>,
and name-lookup iterates over the set.
When loading an old session after starting Ardour, it is very
likely to always lookup the playlist (1), because new, later
allocations from (2) are on top of the heap and ordered last.
The session seemingly loads correctly, except for lingering,
unused empty playlists "toBeResetFroXML" renamed to "Track name"
that were never deleted.
However when loading an old session from a running instance,
ordering is mostly random, and many tracks end up with using
the empty playlist (2) instead of the correct playlist (1).
in 5.x, we would only run the MTC parsing code if slaved to MTC. That's no longer true in 6.0, and without
this change, MTC will cause a locate at startup
This fixes issues with send-panner bypass whenever the
target bus input-count is different from the send's channel count.
--
Previously, when the aux-send panner was bypassed, data was
copied using BufferSet::read_from().
This sets the channel count of the output buffer set (here: mixbufs)
to match the input (here: bufs).
e.g. mono to stereo, "1 in -> 2 out" out was changed to "1 in -> 1 out".
Un-bypassing the panner later does not reconfigure the I/O.
Mixbufs remained mono, and PannerShell::run() "1 in -> 1 out"
does nothing. The panner was effectively not functional.
Locating the start of the loop range at transport start does not count as "have looped". This was preventing
pre-roll when starting to loop, which in turn caused data/event loss because the start/end sample ranges
would be incorrect inside process
This reverts commit 8702ff2189,
and b10d9cf09b.
There was a misconception on the iterator (port vs message
in sequence), besides Ardour's mixer-strip is preferably used
with a single MIDI port. Most plugin-standards also only support
one port.
If need be LuaDSP run_map() can be used to handle multiple
MIDI I/O ports already.
We accomplish this by explicitly setting the global_obs to NULL after
free'ing it. The crash that led to this fix can be replicated as such
$ sendosc localhost 3819 /set_surface i 8 i 159 i 8
$ sendosc localhost 3819 /set_surface i 0 i 0 i 0
$ sendosc localhost 3819 /set_surface i 0 i 0 i 0
In this example the observer is created, then free'd, and then free'd
*again* because the new observer was never made (sur->feedback[x]
checks fail)
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.
Mixbus v6 uses AutomationType BusSendLevel like other Sends,
however with different min/max range compared to default Ardour
Aux sends. Control surfaces should use interface/internal API.
Bug was introduced in 128a45954c, declick-amp gain was
overridden, but declick not cleared. For some reason this did
not affect audio-only exports nor all session exports.
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
This use-case is better served via stem-export.
This export mode never worked correctly when latent plugins
are present on the track. or when realtime export was chosen.
This used to call
track.export_stuff() -> bounce_process()
periodically in small chunks from freewheeling callback,
which is no longer functional.
Ardour's playback is aligned to master-out:
"When the playback clock reads 01:00:00:00, the sample corresponding
to 01:00:00:00 is audible at the speaker(s)"
When exporting, and grabbing data from output ports, the signal
is offset by the master-bus physical playback latency. This was
compensated for, but lead to initial silence in the exported file.
New approach is to start capturing export data during pre-roll,
at the time when playback is written to the output buffers.
To also shaves off a common offset to make this work with
realtime export. Effectively this emulates processing with
disconnected master-output port, while still keeping any
latency of effects on the master-bus itself.
Last but not least: jack updates latencies when freewheeling,
(setting HW latency to zero). The callback arrives asynchronously
some time after enabling freewheeling, but after Export
Ports have been configured. Those callbacks are ignored.
After exporting a time-span, the next time-span was started
directly from the rt-callback. This had various issues.
In particular with realtime export.
Post-processing of a realtime-export enables freewheeling
and is driven by freewheel callbacks. Freewheeling needs to be
safely disabled for an upcoming realtime export.
A similar issues existed when mixing realtime and non-realtime exports.
'lower_bound()' iterates between param #1 and param #2, comparing the result
with param #3 - either by making the comparison internally or by deferring to
an external comparator function. Prior to C99 however, BOTH cases required
param #3 to match the type being iterated.
In the case of a deferred comparison, there was apparently a proposal to
relax this restriction in C99, though I'm not sure if it in fact got
implemented (can't find any examples of it anywhere...)
This allows users to rename sends without enforcing a numeric
bitslot number. However this prevents a user to to use "send" names
that are potentially used for new sends or inserts.
Ardour statically links libardour against zita-convolver,
this is required because it's used in plugins and available
by Lua scripts.
libzita-convolver has been modified to be in a custom namespace
and extern global symbols have been removed.
On most GNU/Linux distros system-wide default zita-convolver
is not compatible nor suitable to be used as-is.
From #ardour IRC:
> there have been a few times that I wished a-Delay could boost volume
> it has an "output gain" slider, but it only subtracts. the maximum is 0db
> delay is a big part of guitar solos, so a boost in the same plugin would be awesome
Otherwise this will lead to a corrupt state:
ERROR: Session: XMLNode describing a AudioRegion references an unknown source id
ERROR: Session: cannot create Region from XML description. Can not load state for region
ERROR: Playlist: cannot create region from XML
and a track without playlist is created, resulting in a later crash.
Eventually SessionPlaylists::load() needs to handle this gracefully,
but this should help catch cases causing the actual issue.
~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.
set_auto_punch_location() is a NO-OP when there's no punch range.
This disconnects `punch_connections`, clears session-events,
and emits auto_punch_location_changed().
The previous approach failed in case where PluginInsert
uses no-inplace buffers with a linear map.
Since buffers are replicated up to a total of number of
all (inputs + outputs), the number of output buffers
could not be determined. There was insufficient information
using the I/O map alone.
With a known number of outputs processing and applying
the i/o map is also a lot easier and faster.
This break the API of process_map().
(valgrind trace, line-numbers from mixbus+6.0-190-g0ec6bc35a)
This may happen initially for unconnected graph nodes,
e.g. Foldback Busses from ARDOUR::Session::post_engine_init().
==29797== Conditional jump or move depends on uninitialised value(s)
==29797== at 0x6167D3F: trace_terminal(boost::shared_ptr<ARDOUR::Route>, boost::shared_ptr<ARDOUR::Route>, bool) (session.cc:2174)
==29797== by 0x6167D99: trace_terminal(boost::shared_ptr<ARDOUR::Route>, boost::shared_ptr<ARDOUR::Route>, bool) (session.cc:2174)
==29797== by 0x6167D99: trace_terminal(boost::shared_ptr<ARDOUR::Route>, boost::shared_ptr<ARDOUR::Route>, bool) (session.cc:2174)
==29797== by 0x616890D: ARDOUR::Session::resort_routes_using(boost::shared_ptr<std::__cxx11::list<boost::shared_ptr<ARDOUR::Route>, std::allocator<boost::shared_ptr<ARDOUR::Route> > > >) (session.cc:2289)
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.
Various operations clear the history (e.g. cleanup). In that
case the GUI correctly had an empty Undo/Redo history, but the
file on disk was left in place.
Next session load restored the old, incorrect Undo/Redo history.
This type of MIDI port fetches all of its data from inside ::cycle_start(),
and delivers it to a FIFO connected to another thread (typically a
control surface).
Unlike regular MidiPorts, which will be read from inside a Session::process()
call, these ports will read their data once per AudioEngine::process() cycle.
They therefore cannot use MidiPort::get_midi_buffer() which scales and adjusts
event timestamps as if the data is being accessed from within Session::process().
It is still an open question whether or not AsyncMIDIPort::cycle_start() should
still scale event timestamps by speed. In some respects it seems more appropriate
to do so, and the reading thread (e.g. a control surface) doesn't care about
the "nframes" limit on timestamps that exists for calls within a Session::process()
tree. For now, leave the timestamps unscaled by speed.
When loading a session with muted tracks, those tracks were
not initially muted, but ardour only faded them out.
The same happened to sends, and also tracks with non unity fader:
an initial fade from unity to target gain was done.
Now this send and deliveries always fade-in (like default Amp does).
"Always use Tabstops for block-indent (the code must be
formatted correctly with "[TAB] = N spaces" for any value of N).
Use space only for alignment." - https://ardour.org/styleguide.html
Session::locate() used TransportFSM::stopped() to determine if realtime stop was required. But this would
return false, since the motion state at that time is WaitingForLocate. So invert the test and use
!TransportFSM::rolling
We told the DR to read from pos+shift, and it increment file_sample[T] appropriately. We should not adjust it. The
only thing that gets adjusted is the sample that will playback (as a result of PlaybackBuffer::increment_read_ptr()
This fixes old session-state of sessions saved after
6.0-pre0-3039-g93180ceea9 and before 6.0-pre0-3459-g587fc50059.
It's mainly relevant for Mixbus6.0
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)