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).
We accomplish this by explicitly setting the global_obs to NULL after
free'ing it. The crash that led to this fix can be replicated as such
$ sendosc localhost 3819 /set_surface i 8 i 159 i 8
$ sendosc localhost 3819 /set_surface i 0 i 0 i 0
$ sendosc localhost 3819 /set_surface i 0 i 0 i 0
In this example the observer is created, then free'd, and then free'd
*again* because the new observer was never made (sur->feedback[x]
checks fail)
Mixbus v6 uses AutomationType BusSendLevel like other Sends,
however with different min/max range compared to default Ardour
Aux sends. Control surfaces should use interface/internal API.
"Always use Tabstops for block-indent (the code must be
formatted correctly with "[TAB] = N spaces" for any value of N).
Use space only for alignment." - https://ardour.org/styleguide.html
This fixes an issue with "/route/eq/freq/0 S1":
When a newly select strip that does not have a EQ
(e.g. mixbus or master), the control from the previously
selected strip is used. -- Reported by tavasti on IRC.
* add an option to the controller configuration gui
to assign the 3x2 send banks in mixer mode
to either the upper (1-6) or lower (7-12) Mixbus sends
* This was a user request to better support the workflow
of the CoMondo Mix system
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.
Some builds of glib on macOS end up delivering IO_PRI when IO_IN is also set. This differs from our own build stack
version, but it isn't really an error, so we should handle it.
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
At least on my machine, the fonts on the Push display were ridiculously large,
making everything overlapping and unusable. I suspect this is because
pango_cairo_font_map_get_default() inherits DPI from the system, so the
monitor scaling factor got applied to the Push display as well.
This commit instead creates a new plain font map, and sets the resolution to
96, which looks like what the UI was designed for. Some more tweaking of the
Pango context might make things more optimal on the Push, but just setting the
resolution makes things look reasonable to me anyway.
It's long been a guideline (and IIRC a Weff-c++ warning) that either all, or
none, of the copy methods should be defined, but this became a standard warning
in GCC9. Presumably to account for a later language change though I'm not sure
which.
I don't remember why the ChanMapping copy constructor can't just be a simple
copy (it's just a map of POD), but figure it's safer to just copy what that
does.
gcc can recognize various regexps in comments. Since C++17 provides
[[fallthrough]], using /* fallthrough */ consistently seems
appropriate until we switch to C++17.
see also https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
This resolves a circular dependency:
libardour calls methods from libardour_cp and vice versa.
Since 9bb2f2bb libardour is also calling active() and that method
needs to be forced to use late binding. -- compare to b9bbea7174
USB stack may not be available on some systems, e.g. unit-test VM.
When libusb_init(0) fails to create default context, further calls
into the libusb API will cause segfaults.
This fixes a potentially undefined branch if the USB device list is empty.
dev is NULL, the loop is never entered, 'r' isn't set.
if (!dev && !r) is undefined.
