Stop the engine if it was started for latency measurement
but measurement was aborted.
Previously the engine was kept running and the "Start' button
was not available.
If this happened during initial session loading, a user
would have to manually restart the engine to proceed.
The dialog is run using gtk_dialog_run() which uses on_response() to deal with delete/close events unlike a regular
top level event loop.
Probably even better would be run run the dialog from the top level event loop, but this is a bit complex
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
When there's no main window (initial setup, no transient parent),
preset a normal window listed in the task-bar.
The duality the Engine Dialog being used as Ardour-WM managed non-modal
Window (Menu > A/M Setup) and modal Dialog (AudioEngineSetupRequired)
complicates this a bit.
It may happen that during push_state_to_backend() a device is
reconfigured in a way that triggers a "Device Changed" callback before
the engine is started. This callback can trigger a change to the
configuration that will be used when the engine is actually started.
This has been seen on OSX in conjunction with Aggregate Devices
(even if the aggregate is not used, but the device which is used
is also part of an aggregate)
example: HW changed callback arrives, device-list is re-populated,
*A*irplay" is at the top of the list, Airplay supports only 44.1K,
Samplerate changes... later save also writes this new rate to the file.
This replaces using ARDOUR_UI::disconnect_from_session which is only used by the
EngineControl class. ARDOUR_UI::disconnect_from_session also disconnects from
the AudioEngine::Halted signal which seems unnecessary as Halted is not emitted
when stopping the engine and calling update_sample_rate() which is already
handled when the AudioEngine::Stopped signal is emitted.
Use a single function with the complete logic.
Since the callgraph is complex, there is internal state as well as GUI
state (different pages), do not rely on individual methods to get it
right.
A widget's sensitivity should only be controlled by one function.
Connect to the backend_combo changed signal after setting state as calling
backend_combo.set_active_text() in set_state was triggering backend_changed(),
which would then see the driver_combo had not been set and set it to the
incorrect value.
The value/name of the backend needs to be restored first then we can populate
the driver combo and set the correct active entry from the saved state. After
which backend_changed() will populate the device combo's etc so they can then
be set to the correct active values from the saved state.
Some refactoring was necessary to avoid code duplication
Restoring of device state for input and output devices still doesn't work
correctly. I'm not quite sure what the issue is at this stage.
connect/disconnect button was connected multiple times
Also the button allowed to start a backend with
invalid settings (after changing backend).
Q: does “Connect to” make sense? It’s redundant with
“Apply”.
