Variables by these names are only used from the local wscript and when
running "waf configure", which already for other reasons only can run at
the top-level.
These variables are thus not mandatory and not used.
* reserve "probe" to actually probe for devices
* use separate probe for libusb and MIDI port devices
* use "available" to check if surface can be used
* allow both methods to be NULL
* remove unused ControlProtocolDescriptor* argument
Most surface just return `true` for available.
This is mostly a simple lexical search+replace but the absence of operator< for
std::weak_ptr<T> leads to some complications, particularly with Evoral::Sequence
and ExportPortChannel.
Keep file-system paths and PBD::Searchpath mostly separate.
This amends 58c2b0a848 libs/fst directly includes relevant
ardour C++ code, so lib/fst must not link against libardour.
The problem was that 58c2b0a848 introduced additional
dependencies on other libardour functions.
DeviceInfo (bindings file) can include explicit motorized
and threshold settings. These values, when specified, are
used during load_bindings() during set_state and overwrote
any user customization.
Furthermore showing the GUI invalidated any prior setting
by explicitly calling binding_changed, which re-applies.
Found via `codespell -q 3 -S *.po,./.git,./share/patchfiles,./libs,./msvc_extra_headers,./share/web_surfaces,*.patch -L ba,buss,busses,discreet,doubleclick,hsi,ontop,ro,scrollin,seh,siz,sord,sur,te,trough,ue`
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
```
MidiControlUI drops the reference to a given controllable in
its own thread. This can happen after the plugin is already
destroyed (even though the PBD::Controllable still exists).
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.
Ardour's "pbd/i18n.h" needs to be included last,
after any include that may indirectly pull in getext or libintl.
For that reason "pbd/i18n.h" must not be used in header files either.
Increment for CC values > 0x40, decrement control for values <= 40.
- 0x41 increment by one
- 0x40 decrement by one
previously: 0x3f decremented by one, 0x3e by two, .. 0x00 by 64,
but 0x40 also by 64.
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.
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.
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.
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.
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
