Previously Editor::instant_save() returned if no session was loaded,
effectively Config->add_instant_xml(get_state()); was never called.
instant save() is called early on, in Editor's c'tor before the editor
is realized and saves invalid window-size and window-state, which
are used later.
under some circumstances, e.g. session-exit it is possible to to have
inconsistent information
ARDOUR_UI::instance()->session_loaded == true
&& ARDOUR_UI::instance()->the_session() == NULL
This lead to a crash on MacOS/X. stopping the engine at exit may destory
an Aggregate Device, leading to DeviceListChanged which in turn updates
the engine-dialog..
else if (ARDOUR_UI::instance()->session_loaded) {
float active_sr = ARDOUR_UI::instance()->the_session()->nominal_sample_rate ();
This fixes issues with analysis and archiving that rely on a readable
to return 0.
Note however that createSilent() uses max_samplecnt (INT64_MAX) by
default. This relies on a region setting the length of its missing
source.
These processors don't have a UI, so their load stats are not easily
visible. The stats can still be queried via Lua API or DSP-load
overview window, so we retain this for debug builds.
Use AU's preset->presetNumber as identifier since std::map are sorted
this also indirectly sorts presets by preset-number. (user presets
start with a '/' and are listed first, sorted by name).
Since Presets are now identified by URI on session load (53a0199a0)
and AU user-presets can added/be removed (since ae4604a24b), simple
sequential numbering is no longer an option.
This is a step in the right direction: first load the preset and
only if preset-loading was successful mark it as loaded.
This still does not properly unset "parameter_changed_since_last_preset".
AU signals "kAudioUnitEvent_ParameterValueChange" later in the event-loop.
There are two cases:
(A) Proxy is created first, dialog is created later on demand
(B) Dialog is created and directly registers its window as proxy
In (B) the dialog is usually on the stack and destroyed when the
ArdourDialog instances leaves scope. In that case ~ArdourDialog()
is called and the proxy remained.
Destroying the proxy does destroy the registered window in ~WindowProxy()
If ArdourDialog's d'tor itself deletes the proxy it would recurse into
itself. Existing APIs e.g. drop_window() likewise delete the window and
cannot be safely called from ~ArdourDialog.
* PortEngine::available() implementation
* AudioEngine::connected() wrapper
Eventually we may re-introduce PortEngine::available along
with a libardour internal port-engine.
