Age | Commit message (Collapse) | Author |
|
This fixes an implicit save when importing files.
The Track's disk-reader is initially created with an empty
source which is later replaced and dropped:
ARDOUR::Session::save_state
ARDOUR::Session::remove_source
PBD::Destructible::drop_references
ARDOUR::DiskWriter::reset_write_sources
ARDOUR::DiskWriter::set_write_source_name
ARDOUR::Track::set_name
Editor::finish_bringing_in_material
|
|
Most calls to new_audio_route() used save = false, only directly
creating busses saved the session. Probably for historical reasons.
|
|
|
|
|
|
loop for loop play
|
|
Since we now (correctly) do not locate for loop changes, this member
is unnecessary
|
|
|
|
|
|
Replacement to follow in subsequent commit
|
|
So far internal-sends were explicitly special-cased, and implicit
solo-state only was only forwarded for direct up/down-stream
connections. ...and nobody can remember why :)
This restriction is removed, so far mainly with commenting-out
code, as experiment.
Internal sends are not only more convenient, but also required
in cases where direct connections result in ambiguous latency.
|
|
Also remove redundant double call to Track::set_block_size(). This dates back to 2010
when there used be an additional traversal of the Diskstream RCU-managed list, before
they became owned by Tracks
|
|
|
|
This is done in order to set the TransportGenerator flag
|
|
We need a MidiStateTracker to determine notes whose end is not reached
during the call to ::write_one_track(), so that we can resolve them
in the output (SMF) source. This required some changes to the ::export_stuff()
API for tracks.
In addition, we now take the source "lock" just once during ::write_one_track()
rather than every time we write. This isn't an integral part of the
note tracking, but fell out along the way.
Finally, note that although we use a vector to handle MIDI "sources" here,
it is expected that there is only 1 MIDI source at present. Leave vectors in
place since it is possible that ::write_one_track() could be modified
in the future to change that.
|
|
|
|
Session::update_latency() may be called multiple times with
the process-lock being held.
|
|
|
|
|
|
jack2 can process in parallel with calling a graph-order or
latency-callback, so Ardour takes a lock to update those in sync.
Yet jack2 can also block while port-registrations happen,
and concurrently emit latency-callback from another thread..
|
|
|
|
Port and connection changes always imply a latency_callback from
the engine. Worst I/O latency is updated directly in
Session::update_latency() which is called from
AudioEngine::latency_callback.
Explicit subscriptions to route->output()->changed() is not needed
to update the worst I/O latency.
Only set_block_size() needs to to update the I/O latency when
the buffer-size changes.
|
|
-DLatency now triggers all four:
* LatencyCompensation (entry-points, overall flow)
* LatencyIO (Port/IO query, set/get private/public)
* LatencyDelayLine (Delaylines for internal sends and alignment)
* LatencyRoute (route processor latency)
|
|
The backend may call update_latency() while at the same time
the auto-connect-port calls set_worst_io_latencies().
The latter already holds the process-lock, so update_latency()
first needs to acquire it, as well. If one already holds the
_update_latency_lock, one must not ask for the process-lock.
---
Previously Ardour's connection manager first took the process_lock
and then waited to the _update_latency_lock.
Meanwhile jack calls latency_callback(), takes the
_update_latency_lock and waits for the process_lock.
Classic deadlock.
|
|
|
|
Various backends have different strategies for updating latencies,
and different thread semantics for latency update callbacks.
With jack2 it is possible that processing happens concurrently
while port latencies are being changed.
Ardour internal backends emit the latency callback from the
main process thread, serializing latency changes with processing.
Various user actions can also trigger latency changes. e.g.
with a stopped engine it is possible to re-order plugins.
|
|
|
|
|
|
|
|
|
|
Since ead883302fe800ae, it is no longer possible to use a null
pointer SessionEvent::track as flag to indicate overriding all
buffers.
|
|
|
|
|
|
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.
|
|
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.
|
|
instrument is added"
This reverts commit fac8d84786f420f91b68ce2e444579ea2162cb8d.
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.
|
|
|
|
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.
|
|
|
|
|
|
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
|
|
0.05 seconds per track
Leave debug output in place for now to get some numbers from any testers
|
|
|
|
|
|
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.
|
|
This is in preparation for GUI sensitivity of Loop and Punch actions.
|
|
This also prevents switching between punch-in/out record
and looping without transport-stop.
|
|
|
|
(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)
|
|
(valgrind trace, line-numbers from mixbus+6.0-190-g0ec6bc35a)
==29797== Invalid write of size 4
==29797== at 0x619BB3F: boost::dynamic_bitset<unsigned int, std::allocator<unsigned int> >::reference::do_reset() (dynamic_bitset.hpp:120)
==29797== by 0x6196002: boost::dynamic_bitset<unsigned int, std::allocator<unsigned int> >::reference::do_assign(bool) (dynamic_bitset.hpp:122)
==29797== by 0x618F670: boost::dynamic_bitset<unsigned int, std::allocator<unsigned int> >::reference::operator=(bool) (dynamic_bitset.hpp:107)
==29797== by 0x617E426: ARDOUR::Session::unmark_send_id(unsigned int) (session.cc:5633)
==29797== by 0x6156714: ARDOUR::Send::~Send() (send.cc:125)
==29797== by 0x5CE12A7: ARDOUR::InternalSend::~InternalSend() (internal_send.cc:71)
==29797== by 0x5CE1319: ARDOUR::InternalSend::~InternalSend() (internal_send.cc:76)
==29797== by 0x1556128: void boost::checked_delete<ARDOUR::InternalSend>(ARDOUR::InternalSend*) (checked_delete.hpp:34)
==29797== by 0x155E689: boost::detail::sp_counted_impl_p<ARDOUR::InternalSend>::dispose() (sp_counted_impl.hpp:92)
==29797== by 0xCC0E30: boost::detail::sp_counted_base::release() (sp_counted_base_std_atomic.hpp:110)
==29797== by 0xCC0EA6: boost::detail::shared_count::~shared_count() (shared_count.hpp:426)
==29797== by 0x134BD15: boost::shared_ptr<ARDOUR::InternalSend>::~shared_ptr() (shared_ptr.hpp:366)
==29797== by 0x60FACC1: ARDOUR::Route::~Route() (route.cc:498)
==29797== by 0x60FAF4D: ARDOUR::Route::~Route() (route.cc:517)
==29797== by 0x166144C: void boost::checked_delete<ARDOUR::Route>(ARDOUR::Route*) (checked_delete.hpp:34)
==29797== by 0x166338F: boost::detail::sp_counted_impl_p<ARDOUR::Route>::dispose() (sp_counted_impl.hpp:92)
==29797== by 0xCC0E30: boost::detail::sp_counted_base::release() (sp_counted_base_std_atomic.hpp:110)
==29797== by 0xCC0EA6: boost::detail::shared_count::~shared_count() (shared_count.hpp:426)
==29797== by 0xCD2385: boost::shared_ptr<ARDOUR::Route>::~shared_ptr() (shared_ptr.hpp:366)
==29797== by 0x615D0E5: ARDOUR::Session::~Session() (session.cc:455)
==29797== by 0x615D4A3: ARDOUR::Session::~Session() (session.cc:461)
|
|
|