Strip::notify_property_changed accesses _stripable without verifying
that is not null. However it is possible for this to be null, so
add a null check.
Only enable the master display and meter modes for Qcon devices if this
surface is in the master position. Extenders don't have master meters
or master displays.
Logic to detect an extender has to be based on if this surface object is
the master position. Has master fader is true for all surfaces in this
"device".
Old and new strings are compared before sending to keep traffic down. To
ensure that we send all the required characters be sure to init the last
value to characters that are never going to appear in a real string.
Space is a bad choice since it is a valid character. Use NUL instead.
The device info file allows key names and values to be configured in each
device file. Use that information when building the Functions Keys tab in
the Mackie protocol setup dialog.
While surfaces are being created it is possible to have surfaces, but
not have a master surface yet. This happens when the config calls
for extenders to the left of the master section. Don't assume that
if we have surfaces, the master surface is available.
This resolves a PBD vs ARDOUR namespace error for some compilers:
```
error: reference to 'microseconds_t' is ambiguous
libs/pbd/pbd/microseconds.h:29:19: error: candidates are: typedef uint64_t PBD::microseconds_t
libs/ardour/ardour/types.h:81:29: error: typedef PBD::microseconds_t ARDOUR::microseconds_t
```
If the wrong device profile is selected (ex Xtouch One) but another device
is connected (Xtouch), it is possible to have a master fader on the
device, but not in the code. This would then cause a crash when the
master fader was touched.
This just protects from a wrong configuration.
In some cases old and/or conflicting port names were saved
with the session (e.g. "Faderport" for FP1,8). Loading old sessions
then merges this state into the config, which could lead to
port-registration failure when the surfaces was enabled.
Follow Session::setup_bundles() lead for single channel
MIDI bundles. This cleans-up the port-matrix display and
removes redundant names. The underlying engine port-name
is not of interest to the user.
Main features: Plugin (Select & Edit)
1. Plugin Select: When a track is selected that has PluginInserts, pushing the "Plug-In" button on a mackie will list these across the strips. Clicking a vpot of a strip enables editing the parameters of this selected plugin.
2. Plugin Edit: When a Plugin is selected for editing, the input parameters of the plugin are shown across the channel strips and the vpot is assigned the corresponsing AutomationControl for the parameter.
Minor features
- When the number of plugins or the number of parameters exceeds the number of strips available on the surface, one can flip through "pages" of views using the Cursor Left and Right keys (this logic I took from http://www.emagic.de/media/support/content/manuals/LogicControl_en.pdf)
- When in the Plugin Select mode, rearranging the plugins in the mixer strip is reflected on the surface.
- When in Plugin Edit mode, rearranging the plugins in the mixer strip still retains the edit view of the selected plugin (rearranging does not take away the current subview)
- When removing a plugin in the mixer strip, this is reflected in Plugin Select, while the view jumps to Pan/Surround (the None subview) when in Plugin Edit mode.
- Removing a track resets the subview to None
- When in a Subview that is track-specific (Track, EQ, Send, Plug-In, Inst), selecting a different track retains the subview but updates the channel displays and vpot assignments accordingly. When in Plugin Edit mode for track A, and track B is selected, it changes to Plugin Select mode for track B (if plugins are present).
Previously this was inherited via PBD.
On MacOS/X, this adds
"-undefined dynamic_lookup -flat_namespace"
and various "-framework .." options to linkflags
Without this flag, .dylibs fail to link usually because
of missing `-lintl` (Undefined symbols: "_libintl_dgettext")
On other systems this is a NO-OP:
CFLAGS_OSX, CXXFLAGS_OSX and LINKFLAGS_OSX
are only set on the darwin platform.
This reverts commit af30a6f001
because it breaks OSX/MacOS builds:
libs/surfaces/mackie/mackie_control_protocol.cc:945: error: 'G_SOURCE_FUNC' was not declared in this scope
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.
