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.
Tracks cannot be rec-enabled at the same as clips/slots/cues/triggers are rec-enabled. This means
that the "rec-enable" button in a TriggerStrip should not be setting track record enabled
status. Instead, it is a GUI-only button that causes a redraw with the appropriate slot
icons (play, record)
Still a bit of work to be done here but functional again and avoids an assert() failure
For some reason, we allow users to trim notes on the timeline when in
draw mode. Not sure why. We don't allow this in pianorolls, so make
sure the cursors don't suggest otherwise
the automation group rectangle, when set to use COORD_MAX as the rightmost x-coordinate
ends up sloping. use a very large number instead.
this ought to get fixed when it can be understood
the split_info for a MidiView would stick around across note selection
operations that really should act as a "boundary" or end of the
split op. This commit ends the split op any time selection is cleared
or notes are added to the selection (except when in the middle of a split
There is one single place in AutomationLine code where we need to callback
to its AutomationTimeAxisView, if it is part of one, regarding automation
state. This permits that to happen
