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
