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.
Add support for smoothing, ignore message when controllers are
not in sync to avoid discontinuous jumps.
This is mainly useful for Mackie-like devices that use pitch-bend
messages for faders.
see also https://discourse.ardour.org/t/feature-lazy-sliders/100961
"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.
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.
Continued work after e9b36f2bea. Prefer a shared_ptr<>.
MIDIControllable::write_feedback() runs in realtime context, directly
from the main process-thread. Synchronizing weak-pointers and deletion
across threads does not work reliably. Retaining a shared_ptr<> for
controllables that are in use can solve this.
This fixes a race-condition when a controllable is deleted
while sending feedback to the device.
Previously there was a race-condition MIDIControllable::write_feedback()
triggered from rt-thread, processed in Surface-thread and deleting
a route or processor.
This is a first step, currently state-restore is not fully functional
session->controllable_by_id() does not cover all Controllables.
(bool) false == 0 == (const char*) NULL
error: ISO C++ says that these are ambiguous, even though the worst
conversion for the first is better than the worst conversion for the second:
actions.h:92: note: candidate 1: Glib::RefPtr<Gtk::Action> ActionManager::get_action(const char*, const char*, bool)
actions.h:91: note: candidate 2: Glib::RefPtr<Gtk::Action> ActionManager::get_action(const std::string&, bool)
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()
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
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.)
in the mixer mode secondary functions
(Device/Hold) of knobs per track
will map as follows:
Send A - trim (same as for Ardour)
Send B - HPF Freq
PAN - Compressor threshold
In the Controller's settings you can now
choose between two operation modes:
1) 8 track mode
2) 7 track plus master mode
In case 2) fader 8 is fixed on the master
