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.
If we decide after fast forwarding that this TriggerBox has no triggers
active at the transport position, we must mark _currently_playing as null,
because otherwise the TB can still start the transport (in error) during
run()
Because MIDI triggers compute buffer-relative timestamps using
timeline_samples - start_sample, this already takes into account
any offset to the start of the trigger. We still need to use dest_offset
if a non-zero value was passed into ::midi_run(), but we do NOT
want to have it contain the "offset to start of trigger in process
cycle" as well. Instead of trying to special case
::maybe_compute_next_transition(), we just pass a dummy pframes_t
to that method, leaving dest_offset as it was passed into ::midi_run()
