For MSVC, the parameter 'false' (i.e. 0) can be considered as either a bool or a pointer - so it'll map to both declarations of ActionManager::get_action()
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.)
Generated by tools/f2s. Some hand-editing will be required in a few places to fix up comments related to timecode
and video in order to keep the legible
This may need some small tweaks for MB channelstrip to set
print-format (like LV2 plugins would) for cases where the default
value_as_string() differs.
* Depending on individual strips to watch the selection property is prone to failure.
* Stripable_selection_changed() is called when a selection operation is completed.
The Editor continues to notify them, but via a direct call to ControlProtocolManager, not a signal.
The CP Manager calls the ControlProtocol static method to set up static data structures holding
selection info for all surfaces and then notifies each surface/protocol that selection has changed.
The previously-commented code is precisely what gets invoked
when solo state changes, and had nothing to do with actually
changing solo state in any way.
