* intercept {pgm|bank}-change messages, and replace them with triggerbox values
* check is_set() extensively; we have arrays of pgms but most are unused
* initialize patches to GM standard (drums on 10) in case file has none
* in the case where file had none, check the Auditioner to see if user set any
* in the case where a file has patches, use those instead
* also stash the UsedChannels so we can show only the used chans in the UI
* if a file has program-changes, then it will set() my patches
* if a file does *not* have PCs, the user might choose one (which sets() it)
* if the next file does *not* have PCs, we should preserve the user's selection
* if the next file has PCs, it will set() it (losing the user selection)
we screen midi files for some aggregate info:
used channels, used patches, and note-count
you can't do this from open() because there are cases (after importing)
when the source exists but it is not yet written to disk
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.
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.
```
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()
