This allows to special-cases session-specific control-surface state.
e.g. midi-learn.
Only restore midi-learned, session-specific, bindings when loading a
session with generic-midi enabled.
Also dis/re-enable generic-midi resets midi-learned, but no other
session-independent settings.
This also handles the edge case:
1) load global config, generic-midi = ON, w/ bindings.
state is remembered as cpi->state
2) load session-condig, generic-midi = OFF, cpi->state is retained
3) user enables the surface, cpi->state from (1) is applied.
-> invalid bindings applied -> fail
Keep latest surface configuration, regardless if surface is active
or being deactivated. Current state after de-activation is retained.
Currently state loaded from a session overrides global state from
global preferences, if the surface is marked active in the session.
This is to allow midi-learn.
generic-midi and session-specific midi-learn will require additional
work.
Midi meters are using linear 0..1 range, (not decibels, no log-scale
falloff).
If a track is deactivated, run() is never called. the queued reset never
executed and the meter remained at the initialization default -inf
(visually it looked like a pegged meter).
The checkbox is not kept in sync with
Session > Properties > Timecode > JACK Time Master
besides, it relies on JACK, relies on ardour being the first jack client
and also is mostl useless due to tempo-ramps not being supported by
many jack clients.
Sometimes the interthread process window dialog reports "cancelled"
when it was not actually cancelled, it was just hidden and reshown,
Since we are polling the cancel state interthread, we must reset
the cancel status BEFORE the dialog is shown, and never toggle the
cancel state unless it is a true cancel action by the user.
Rationale: This change is trivial, but Ardour's behavior of refusing to move right one channel unless a full bank remains has been there for a long time, and there are probably good reasons for it. This design was likely conceived when all MCP-compatible devices had banks of 8 faders anyway. However, with the advent of affordable single-strip devices like the X-Touch ONE it becomes a real issue.
Single-strip devices can only access the first channel in the current bank, so relaxing this restriction is the easiest way to enable such devices to access all strips, while still maintaining the usual bank size of 8. Note that maintaining a bank size of 8 is beneficial even with single-strip devices for several reasons:
- It allows use of the bank switch buttons to flip through a large number of strips more quickly.
- It maintains compatibility with existing device descriptions. E.g., the X-Touch ONE can be used with the existing X-Touch device description without any ado.
- Most importantly, it maintains compatibility with other MCP-compatible controllers which do have 8 strips and may be connected to Ardour at the same time. E.g., one might want to use an X-Touch Mini, or even a full-size X-Touch along with the X-Touch ONE in some use cases. Changing the bank size to 1 affects all connected MCP devices, so you'd rather keep the bank size to 8 in such scenarios. (Ardour should preferably have separate bank size settings for each connected MCP device, but that isn't possible right now since only one MCP device description can be active at the same time.)
Without this, the visibility tracker will report that the window is not visible at startup, and
this overrides the XML _visible property which denotes that the window should be made visible
