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...
