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