The initial calls in `we_have_dependents()` was redundantly setting
all widows to "Hidden", before the actual state was known.
tabbable_state_change() is initially called for all Tabs:
ARDOUR_UI::setup_windows -> add_to_notebook() -> attach(),
or for detached windows Tabbable::set_state() -> hide_tab().
Step_up/down_through_tabs used window visibility to determine
candidates. This incorrectly considered detached visible tabs.
Detached windows cannot be cycled to.
This also addressed an issue where tab-buttons state was
incorrectly unset what unrelated tab state changed.
ImplicitActive of the currently active tab is now retained
when some other window is attached/detached.
Since 6.0 take-name was not updated correctly:
The name changes in Session::non_realtime_stop(). At that
time tracks are still record-armed and ignored name changes.
Newly created tracks also never had a diskstream name set
correctly. This only happened at session-load via set_name(),
or config change.
This add support for special-cased automation controls
(Fader, Trim, Panner, Mute) and spills their automation-lane
on touch.
It also features a small internal API update directly mapping
CheckMenuItem. See also bd8c26a059
Symlinks are expanded when rolling the .dmg, which leads
to errors during signing and notarization, so copy files
as needed.
This also removes excess files in etc/ (which are also symlinks),
and avoid empty folders and fixes library path in sub-folders.
playlist->partition() calls DiskReader::playlist_ranges_moved()
which may add Panner and Fader automation state changes.
The reversible command has to be started before calling
playlist->partition(). Simply collecting playlist->rdiff() after
the fact is not sufficient.
This is is useful to determine if an undoable action was
performed before adding additional information (e.g. selection
changes) to the undo transaction.
Since switching to StartupFSM, the GUIIdle signal isn't available
connected at application start. The splash-screen was blank until
the main UI was up.
"Ardour is ready for use" was the only visible message.
Method Session:locations():range_starts_at(pos, slop, incl)
to search range by start point with some inaccuracy delta.
Similar to mark_at(pos, slop)
Method Session:locations():add_range(start, end)
to create new range and get it for later changes.
For some unknown reason, VC++2019 won't let us take the address of std::list::unique() - although other std::list members seem okay. I've spent weeks tracking this down but there's no fix available AFAICT.
I've flagged it up to the MSVC development team - just don't hold your breath !!
Do not simply allocate std::vector<> space but also initialize
elements. The data is later accessed as C-pointer array: &var[0].
With most compilers simply reserving space in the vector is
sufficient in order to later access the elements directly.
However actually placing objects in the vector before referencing
them is more correct.
If a plugin implements Vst::IComponent::set_state() but
does not implement Vst::IEditController::setComponentState()
nor dedicated get/setState interface for the IEditController,
querying the parameters using Vst::IEditController::getParamNormalized()
returns values that do reflect the restored state.
In this case the host needs to save/restore all control-parameters,
and ignore values reported by ::getParamNormalized().
This fixes a state save/restore issue with softube.vst3, however
vstpresets are still broken: the GUI (IComponent) is updated,
however the controller isn't.
This fixes crashes with plugins calling setDirty() when the
UI is closed. `plugin` has already been reset before
the actual window is closed:
`PluginUIWindow::~PluginUIWindow()` runs, and destroys the window,
here `~VST3NSViewPluginUI ()`. This closes the VST3 view, which
triggers a `VST3PI::setDirty`.
At this point in time `~PlugUIBase()` has not yet run, so all
signals are still connected.
setDirty() ends up calling PlugUIBase::update_preset_modified()
which access `plugin` pointer, which is NULL.
