The cross-over point of an exponential fade occurs further towards
start of the fade. This increases consistency of cross-fades moving
the cross-over point to the center of the fade.
Also looped material is likely correlated in which a linear fade
is more appropriate.
This is only relevant when automating a plugin-bypass, due to
ActiveChanged the following could happen from the realtime thread:
#2 ARDOUR::Session::update_latency_compensation (false, false)
#3 PBD::Signal0<void, PBD::OptionalLastValue<void> >
#4 ARDOUR::AutomationControl::actually_set_value
#5 ARDOUR::PluginInsert::PluginControl::actually_set_value
#6 ARDOUR::PluginInsert::connect_and_run
#7 ARDOUR::PluginInsert::automate_and_run
In this specific case the update_latency_compensation()
is called with process-lock held but the caller lied:
called_from_backend=false
When a delayline update is needed, this can lead to a deadlock,
since the process-lock is acquired again.
Simply postponing the update is preferable since this also
postpones the change when actively recording.
PS. This may need special casing for freewheel export.
IO::latency iterates over the port-set retrieving the
private_latency_range of each port. The value can cached
since it can only change when connections or latency changes.
see also 40eefeddd6
In theory the GUI is single threaded and registration of
events happens only when a plugin GUI is constructed or
destroyed (which happens in the GUI thread).
Except it seems that if a plugin uses reference counting,
un-registration can happen later.
This is to allow passing the EventType to the Buffer, using a
consistent {[Time], Type, size, data} API, that is equivalent
for all classes.
This is particularly useful for Lua scripts and plugin UIs
than can call `write_immediate_event()` while being ignorant
where the data is routed to (MIDI tracks, plugins, processors).
The motivation for this is to determine if a given event
originates from a user-controlled live input controller or
from playback from disk or a MIDI file.
This distinction is required for VST3 MIDI learn.
When closing a session without loading or creating a new one,
Ardour's main window and menu are accessible.
Menu > Session > Properties : crash w/o a session
Menu > Window > Transport Masters : any interaction causes a crash.
This is required. From the "RestartFlags" documentation:
> kLatencyChanged:
> Latency has changed The plug informs the host that its latency
> has changed, getLatencySamples should return the new latency after
> setActive (true) was called The host has to deactivate and reactivate
> the plug-in, then afterwards the host could ask for the current
> latency (getLatencySamples) see IAudioProcessor::getLatencySamples
Some plugins correct their own size when resized which can lead
to endlessly growing GUIs. In particular this issue exists
if Ardour's plugin-toolbar forces a plugin to grow in size to fill
the allocated space. While the plugin aims for fixed aspect-ratio.
This will need a proper solution involving VST's checkSizeConstraint,
however GTK+2 does not have an appropriate API...
