Regular .h files *should* be self-contained and independent of previous
includes and guarded to only include once. Make it clear which files
that *doesn't* apply for at all.
the rest from `tools/convert_boost.sh`.
* replace boost::function, boost::bind with std::function and std::bind.
This required some manual fixes, notably std::placeholders,
some static_casts<>, and boost::function::clear -> = {}.
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`
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.
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
This also removes enums introduced to describe well-known parameters for Mixbus. Lookup now involves string
parsing every time, but this is not likely to be a notable cost.
This reverts commit 561c8eea0c.
It is rare that a device needs sysex-initialization every time it is
connected, besides a single simple "Sysex" entry without options
is not very flexible.
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
When there are some non-released MIDIControllables, signal are still
delivered to the objects, even if there's no surface thread to handle
the signals anymore.
- GMPC does not use it directly
- when GMPC was enabled Stateful::loading_state_version was set to 1000
(the protocol is at 1.0.0)
- it messes up session-loading, particularly various plugin states and
templates (e.g Processor::set_state_2X was used)
