Age | Commit message (Collapse) | Author |
|
This also prevents switching between punch-in/out record
and looping without transport-stop.
|
|
|
|
|
|
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().
|
|
|
|
Previously this could assert(), copying a buffer to itself.
|
|
(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)
|
|
|
|
|
|
This fixes various cases where SessionHandleRef shared_ptr<>
were kept when sources were removed.
|
|
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.
|
|
|
|
Previously the region was only removed from the Session's
region_map without sending notifications.
|
|
|
|
Code only handled a reversing->rolling path, not reversing->stopped
|
|
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.
|
|
|
|
This is in preparation to fix a
"SessionHandleRef exists across session deletion"
error.
|
|
|
|
|
|
This also emits DirtyChanged() only if needed.
|
|
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).
|
|
|
|
|
|
So far only MacOS/X CoreAudio supports this. This is intended
for defualt values in case a user has not callibrated the device, yet.
|
|
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
|
|
canonical
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()
|
|
"shift" offset
There is still a bug related to "shift" that causes a playback discontinuity
|
|
reversing
|
|
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
|
|
management and motion state (partially) into TFSM
|
|
|
|
some reverse internal seek allowance
|
|
enough (read direction must match)
|
|
|
|
|
|
was done last time we read from disk
|
|
|
|
|
|
method, rather than Route::set_name()
Without this, nothing in Track::set_name() is called, which means that tracks created from templates
do not get their name set appropriately
|
|
|
|
This handles some special cases where a plugin is added after
the disk-writer but before the disk-reader.
The plugin may add/remove ports (e.g. an instrument: MIDI to audio,
or some stereo to mono processors). However we need to ensure
that any data that is recorded will be played back.
This is a new take replacing b2bc934e2.
|
|
This reverts commit b2bc934e218a8ed05b6f37edc5585191e60ca288.
The commit does causes issues when a user manually removes channels:
The disk-reader's ::can_support_io_configuration() at first ignores
the user's request, forcing the output channel count to match the
DR's current channel config.
However, when configuring the DiskReader after that, channels is updated
to match the new input-count.
Even though the DR itself only plays back using the confgured I/O,
all processors after it still use the old channel count.
Only a later, second re-configuration step will apply the actual removal
to plugins and port.
PS. the original commit was mainly intended to fix a crash when
adding an instrument plugin *between* disk-writer and disk-reader
on a MIDI track.
|
|
|
|
DiskReader::refill_audio and DR::run() do check if a given playlist
is available. This is required for upcoming changes to set
DR channels to unconditionally match DiskWriter.
|
|
|
|
|
|
This is in a Route method, so it is obvious that dynamic_cast<Route*>(this) will return true
|
|
This was a leftover from changes made for Tracks Live, related to
the concept of an auto-return preference. We don't use this anywhere in Ardour
or Mixbus, and the concept should eventually be removed entirely.
|