Changes need to be propagated to the Stripable's PresentationInfo.
So far this was not done for batch-changes using the mixer's left
side-bar "Show all", "Hide all" actions. They remained local
to the mixer and were not persistent.
StripSilenceDialog will now retain its threshold, minimum length, and
fade length values from run to run.
This is done via Session::add_extra_xml() and recalled during the
construction of StripSilenceDialog via Session::extra_xml()
* unify line-width calculation
* thin line-width, approximate thickness of
glyph stroke width at same UI scale
* don't use outlines (except main tool buttons)
This fixes issues of generic buttons with bright-theme
* pixel align some lines
* Don't store tags from plugin's own metadata
Those are set during plugin-scan every time
* Save user-tags even if they're not new
* Reset tags to factory-file tag (if any)
Old user tag files (prior to this commit) are interpreted
as "factory-file". This will auto-correct after the
first save_tags().
Inform plugins about host theme (fg, bg colors) and UI scale-factor.
The latter follows an implementation already present in Carla and DPF.
These extension use proposed official URLs.
This removes a border painted in the host's UI theme color around
any plugin UI.
This results in a much nicer look/feel for plugin-UIs that have their
own theme
Parent class d'tor runs after derived class d'tor. By the time
~TimeAxisView() is called, the actual object has already been
deleted and dyanamic_cast<RouteTimeAxisView*> or
dynamic_cast<AutomationTimeAxisView*> will fail.
CatchDeletion() needs to be emitted from the actual d'tor of the object.
There are currently three non-virtual TAVs:
* RouteTimeAxisView
* AutomationTimeAxisView
* VCATimeAxisView
The first two already directly emit CatchDeletion(), there's no need to
call it again from ~TimeAxisView().
When a plugin is deleted, automation-lanes of the given plugin
are removed, but previously a pointed to the deleted lane remained
in the selection.
This caused crashes later when the track selection is used. e.g.
during sensitize_the_right_region_actions()
Note that ~TimeAxisView() also emits CatchDeletion (this);
however "this" fails to be dynamic_cast<AutomationTimeAxisView*>
because that d'tor has already been completed.
Plugin analysis uses a GUI thread instance of a given plugin to
perform a IR analysis.
Some plugins can be rather CPU expensive to analyze.
e.g. a-hi/lo-filter when interpolating is recalculating biquad
coefficients every 64samples during the 8k IR analysis. This can take
a significant amount of time on older CPUs.
Furthermore live-signal collection happens in the rt-thread,
using cross-thread signals. Signal collection is periodically initiated
from the same timeout signal as analysis.
Analysis is was done using default thread priority, which is higher
than the GUI redraw priority (PRIORITY_HIGH_IDLE).
So it was possible to contiguously initiate analysis, loading the CPU
and preventing redraws.
