Rater than having each Delivery Object provide a Ringbuffer,
which is unused most of the time, the GUI will provide
them on demand.
We need to be careful of lifetime, and use `rt_safe_delete` in
case the Delivery holds the last instance.
Depending on fftw version, compile-flags and availability of
`fftwf_make_planner_thread_safe` fftw_plan_* may not be
called concurrently (fftw internally uses a static cache).
Previously directly using Luawindow::instance() was able
to create the window, bypassing the Window Manager, this resulted
in two issues, the first being rather significant:
* `LuaWindow::set_session()` was not called
* The Window was not maked as visible in the Window menu
This speeds up selection changes when the Region Properties
are show in the bottom attachment and long regions are
selected.
The RegionEditor is destroyed when selection changes and has/had
to wait for the peak analysis thread to complete.
NoteBase-derived note objects must delete their children, because
often they are deleted long before the parent (group) is. However,
in MidiView::clear_events() we used to call _note_group->clear (true)
first, which would delete the canvas items owned by these objects,
without them knowing about it. This made it dangerous for them
to delete those same items in their destructors.
This reverses the ordering so that NoteBase objects are deleted first
(along with their canvas items) and after that we clear _note_group
which will address any danging canvas items created there that are
not owned by a NoteBase-derived object
GTK+ 2.x only looked up action *names* and ignored the namespacing offered by
action groups. This means that if there are two actions in different groups
with the same name, GtkUIManager may not find the one intended when it is
referenced in a menus definition file.
This commit changes that - if the action name contains a '/' character it is
assumed to contain both the action group name and the action name, and it will
only look for the action within the named group.
Notably during realtime export an explicit flush of async
MIDI ports will duplicate port buffer content.
AsyncMIDIPort::cycle_end () calls `flush_output_fifo`,
and `flush_buffers` is called from PortManager::cycle_end.
