On macOS, `context->get_targets ()` may be empty when dragging.
In this case the Clip-Picker assumed that a slot is about to
be dropped and switched to the local clip library.
This in turn cleared selection and it was no lnger possible
to drag any clip out of the library.
This prevents a crash at exit if the analyzer is still analyzing
when Ardour terminates. A possible downside is that an ongoing
analysis will keep the application running for a bit longer.
When auditioning is started, transport controls are disabled
via `set_transport_sensitivity(false)`.
This prevents <space> from being handled:
DEBUG::Bindings: binding for Key 32 (space) state 0 : Transport/ToggleRoll - insensitive, skipped
So the key event is passed on, and can reach the clip-picker treeview
where <space> selects and/or activates a row, which re-starts
audition.
ARDOUR_UI::toggle_roll() cancels audition when audition is active,
so this action should be sensitive, even while auditioning.
This is mainly because Glib::Threads (g_system_thread_new)
uses pthread on Un*x, but on Windows relies on GThreadWin32
(HANDLE)_beginthreadex
This later causes issues e.g. in BaseUI::run()
```
unhandled exception (type Glib::Error) in signal handler:
domain: g_thread_error
code : 0
what : Error setting new thread priority: The parameter is incorrect.
```
For example, the following log text creates a markup error that results in
the session loading dialog being completely empty.
WARNING: VST3<C:\Program Files\Common Files\VST3\Plugins.VST.Someplugin.vst3\Contents\x86-win\Plugins.VST.Someplugin.vst3>: Invalid Module Path
...
Gtk-WARNING **: 16:46:28.447: Failed to set text from markup due to error parsing markup: Error on line 7 char 40: ?Files\Common? is not a valid name: ?\?
The explicit disconnect in the destructor prevents any more signal->connection firing, but the invalidator
is required to remove existing queued slot calls in the receiving thread
Note: this still seems suspicious: we explicitly disconnected from signals in the destructor. However,
it is better form to be able to use invalidator() in the connection call
At some point during code refactoring, we ended up setting up the 3 transition times, intedned
to define when the *previous* transition occured, as we checked to see if a transition
would occur during this ::run() call. This led to (in particular) MIDI clips ending early,
because the transition_beats value was set to the *next* (upcoming) transition, and we used
this to define the timeline position of MIDI events
This allows for a different quantization to be used when WaitingToSwitch,
used when we explicitly start a different Trigger. When "just stopping"
we continue to use 1 bar quantization; when switching to a different
Trigger we use the quantization of the next Trigger
A trigger can be in a playout state when we decide to change its
state to WaitingToStop (e.g. due to a cue marker). This design
leaves the playout condition "in effect" despite the state changing.
This uses a mild trick to pass both the object and ptr-to-member-function from the child class
to the parent class.
Note: before this commit, both instances of ::start_and_roll_to() were identical.
