MidiTrack::restore_controls is triggered by SessionLoaded
event. Yet MidiControl::actually_set_value checks if
_session.loading() is true and postpones sending actual
events to the synth (which may not be fully loaded).
Before 5d02970de8, Session::post_engine_init unset
"Loading" flag early on, so "loading" was already unset
by the time `SessionLoaded` was emitted.
Disabled tracks cannot be selected, so "apply to selection"
does not work to reactivate track... unless it has just been
deactivated. The Selection is not cleared when changing active
state.
this fixes issues with MIDI region recording, which otherwise never
goes through the code path required to "fix" the nascent data into
sources and regions.
This fixes a crash at exit for some Linux VST3s when Ardour
calls ::release_factory() before unloading the module.
The plugin will then also call unref the hostContext. Previously
the lookup interface for the host context was provided by the
plugin; which at that point in time was already deleted.
Previously this caused deadlocks (read lock while holding
write lock), and also not dropped references of plugins.
Ideally undo/redo of FX unrelated region state
will not re-instantiate plugins; we can optimize this later.
various LV2 callbacks from plugin DSP/GUI use raw port_index,
not nth_parameter. This lead to incorrectly queued updates
(_values_last_sent_to_ui) and since 7dac8994f6 to
potential crashes (invalid _controllables[idx]).
See also a1ba561cc5. JACK2 and pipewire unconditionally
report 32kB, Ardour internal backends report 8kB, also
independent of the buffersize.
While jack1 by default announces the audio buffersize.
A sensible value assumes that the GUI reads the FIFO at
a least 25fps, while also allowing MIDI ports to merge
data (hence 2 * raw_buffer_size). Yet limit to 64k per track.
Since RegionFx are significantly simpler compared
to processors, missing plugin state can directly be handled
in the implantation without creating a subclass similar to
UnknownProcessor.
Previously there was a race condition. DiskWriter::run()
cleared the gui_feed_buffer before writing new events.
If the GUI thread had not yet picked up the events by then
they were not displayed. Furthermore due to the try-lock,
some events may have been written to the buffer in the first
place.
This fixes missing events (notably stuck notes) in the red
record box while recording MIDI.
_output latency was not used for those. Processor automation
was not affected.
This also fixes the visual offset of automation vs buttons/slider
when the transport is not running.
When removing instances from some RCU managed list or vector,
they can still live on as shared_ptr references on the
RCU's dead wood stack.
In many cases this is not an issue, in these cases it's prudent.
see also 44610c7877
This riffs off the previous commit, a simple way to replay
ctrl events without re-evaluating plugin automation line.
There may be a better way to handle this (e.g. replicate the
plugin for display only, evaluate on the fly in the UI thread)
Short of redesigning our disk-reader/playlist/region infrastructure
this is likely a sucks-least compromise for the time being.
This still does not work on macOS. closing a session (using
the menu) while the dialog is visible still causes a crash:
`unload_session()` completes and destroys the session
before the dialog's run() method returns and destroys the dialog.
