This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Import via Drag/Drop previously worked by selecting a track,
and then importing to the selected track.
This approach fails when the selected track is in a track-group,
and selecting the track also selects other tracks of different type.
Now the track to drop onto is passed directly passed through to
::finish_bringing_in_material as existing_track.
This also changes TriggerBox Selection to act on release
(like all other selection). Otherwise strip selection will
de-select the TriggerBox on mouse-release.
When importing a multi-track MIDI files with identical track-names,
Ardour would create the same file for each track. Effectively
overwriting an existing file.
The following MIDI file would create the same file twice
in `interchange/`, once for each MTrk.
```
MFile 1 2 240
MTrk
0 Meta SeqName "Foo Bar"
0 TimeSig 4/4 24 8
0 Tempo 666667
0 Meta TrkEnd
TrkEnd
MTrk
0 Meta TrkName "Foo Bar"
0 On ch=10 n=36 v=95
...
```
Previously a triggerbox_ui.h change triggered a complete UI
rebuild. This follows the concept of other editor_selection
lists which use forward declarations.
This is in preparation for allowing to drag trigger-regions
or trigger-slots. Those will not use a static singleton
PublicEditor API.
Additionally this constrains Ardour-internal drags to Ardour
(via Gtk::TARGET_SAME_APP).
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.
Paul Davis
Robin Gareus
Mads Kiilerich
Ben Loftis
luz paz