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)
