There are various ways to cancel a dialog. Only checking for
RESPONSE_CANCEL is not sufficient. e.g. Esc causes a delete-event.
* Gtk::RESPONSE_CLOSE
* Gtk::RESPONSE_REJECT
* Gtk::RESPONSE_DELETE_EVENT
* Gtk::RESPONSE_CANCEL
* Gtk::RESPONSE_NO
Among others this fixes "Clicking session > open,
then hitting ESC opens the currently selected folder and session"
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).
If the file has a timestamp, it should be set in the region during import.
This keeps the BWF timestamp from being lost and allows the region context
menu item "Move to original Position" to work.
It does not affect where the region will be positioned during import. That
still follows the import dialog menu selection (playhead, session start,
etc). It just maintains data that the user can decided to use if needed.
This change also allows files to be imported to the source list and then
later placed on the timeline in the correct timestamped position.
