Until we have a trimmer, the clip length spinner sets integer beats (beatcnt)
This allows the user some minimal ability to fix a clip of the wrong bpm.
We assumed that 'clips' are already be pre-trimmed to a beat length.
Our internal heuristic always forced tempo to match an integer beatcnt
However: when bouncing a Range to a Trigger Clip, you can know the tempo, and also have a non-integer beat length.
In those cases, the clip-length spinner could behave oddly.
While it's arguably wrong to show integer beats when the internal value is something else,
we still want to show the spinner in integer beats, so it remains usable for its main purpose
Lifetime management of Triggers is unlike anything(?) we've dealt with in
Ardour so far. The parent object (Triggerbox) has a normal lifetime
pattern, but Triggers can come and go in a way that few other objects
do (although Processors and particularly PluginInsert are somewhat similar).
We do not want the GUI to hold references to the actual Triggers, because the
end of life of a Trigger is not really a signal for the GUI element to go
away (the Trigger will be replaced in the slot). Consequently, we do not
want TriggerPtr used as a member variable anywhere in the UI. Instead we use a
TriggerReference which can "lookup" a Trigger on-demand (by box and slot
number). The (G)UI now uses these exclusively.
Work still needed to pick up trigger swap signals from the boxen.
