The InstrumentSelector keeps a PluginPtr reference to all
instruments. By default Ardour does not destroy the editor
at exit, So 3 instances of Instrument Selector can remain
* TriggerClipPicker in the editor sidebar (owned by _editor)
* TriggerClipPicker on the TriggerPage (owned by trigger_page)
* SoundFileOmega (sfbrowser owned by Editor)
If a shared_ptr reference is retained, VST3 Module is not
unloaded at exit. This leads to issues with various plugins.
eg. Reason Rack does not terminate, Ardour hangs at exit.
This allows UI scripts (saved in preferences) to access
os.* functions (non-sandboxed), while preventing other
scripts to do so.
Lua scripts that can run os commands can execute arbitrary
code on the system. While this is a nice feature, it can be
equally dangerous.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Having current_time as a public alias of the private last_when did not
add any clarity to the abstraction of last_time. A small step, but still
room for improvement.
Much like the edit-tool and grid-types, clock-modes are UI state.
Saving the UI state separately allows them to be used
consistently for new sessions. Previously clock-modes were set
initially (at application start) and when loading sessions.
The clock modes of newly created sessions was different
depending on loading another session prior to creating the
session. This is now no longer the case.
These were preventing Ardour from compiling on Windows (Clang or MSVC)
Possibly would've been buildable with MinGW but I don't have that available to test.
Region actions are generally set insensitive whilst recording, so
special-case the "add-region-cue-marker" action by explicitly enabling it
when starting to roll in record. Additionally, the action becomes disabled
again after it's been executed, so re-enable it after queuing the cue when
recording.
When loading the very first session is canceled (e.g.
sample-rate mismatch -> Do not load session) or fails otherwise,
execution returns to the startupFSM.
Loading another session after that then takes the same path again:
StartupFSM::dialog_response_handler() -> StartupFSM::engine_running()
-> ARDOUR_UI::attach_to_engine()
The call needs to be idempotent, otherwise setup_windows(),
create_editor() etc are called a second time and Ardour crashes.
* Fix demo-session glob (missing "*" + session_archive_suffix)
* Copy demo-session also when copying settings from older version
* Also add demo-session to recent-list if it was previously unpacked
for new major versions.
The "ask about deletion" dialog will run a recursive main loop
which will call idle handlers, which could call the visual change
handler if the playhead is rolling. VTL is assumed to stoll
exist when this is called
Robin Gareus
Paul Davis
Mads Kiilerich
John Emmas
itmuckel
Colin Fletcher
sra
Ben Loftis
Houston4444