The engine setup identifies devices by name (device list is a map<>
with the device-name as key). To support multiple devices with the
same name, the name needs to be unique.
So far this is achieved by simply adding a number suffix starting with
the 2nd device (this allows to re-use configurations).
Ideally we'd use UUIDs or unique device IDs to handle this, and also
somehow clarify which device is which...
Assume the following connections
Audio -> Bus1 --aux-send--> Bus2
Prior to this commit, Audio -> Bus2 was marked as "direct feed",
even though the connection was only indirect via an aux-send.
This caused issues with implicit solo and could lead to stuck solo.
* Restore active state of devices after measurement
* Don't manually set latencies for measurement (backend handles this)
* remove superfluous call to stop measurement
"last_controllable_value" is using midi value range (0..127).
It is used to compare received midi-value with the actual controllable
for non-motorized surfaces, and this change allows the first
event to already be in_sync.
Previously the first MIDI-event was usually ignored (because
last_controllable_value was out of bounds or didn't match the 0..127
range.
The singleton ActionModel provides a Gtk::Treestore of all actions known to
ardour.
To be used for example by surface control editors to implement action bindings.
Since we (since ddfc37e4) set the UserDown flag for the User button actions, we
need to set it also when we lookup actions when saving the state.
Furthermore, we need also look for the UserDown flag, when we set the state
of the configuration combos for the User button.
The GUI should be notified about the tearing down of the control
surfaces *before* the protocols are actually destroyed.
On ProtocolStatusChange ControlSurfacesOptions::selection_changed() might try
to access protocol->has_editor() of a protocol that happens to be selected in
the preferences GUI. I this protocol already has been destroyed, a crash will
occur.
This improves consistency for the various new-route descriptions
and allows to unify messages with Mixbus without re-doing complete
strings. It may also benefit translations.
