| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
loop and ports
|
|
|
|
|
|
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
|
|
extended to the other libs)
Stage 2 of 3 (more to follow)
|
|
"i18n.h" needs to be included last (after any includes that may indirectly
pull in getext or libintl etc)
|
|
(Mixbus itself will probably need extra changes)
|
|
|
|
(this also needs ardour_genericmidi to link to both evoral and boost-regex)
|
|
KNOB/DIAL to a toggled controllable.
No intent to change Ctl_Momentary or Ctl_Toggle behaviour, plus I tried to document what they are intended to support
|
|
code (the only user).
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.
|
|
|
|
|
|
using different versions of the SESSION_FILE format
|
|
|
|
This reverts commit 561c8eea0cfa45f0b54461b149b4c330e0bbaa3b.
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
|
|
|
|
Note: Control-surfaces should always use interface_to_internal()
and internal_to_interface().
|
|
Fixes restoring the feedback interval property, but as the mutator/setter
method doesn't seem to be used this change should have no affect.
|
|
Stripable selection changes
The Editor continues to notify them, but via a direct call to ControlProtocolManager, not a signal.
The CP Manager calls the ControlProtocol static method to set up static data structures holding
selection info for all surfaces and then notifies each surface/protocol that selection has changed.
|
|
Equivalent to PBD::string_is_affirmative()
|
|
|
|
|
|
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)
|
|
|
|
is received
|
|
|
|
|
|
That commit accidentally removed unrelated code in generic-midi surface
which just happened to have the same name (get/set_midi_feedback) as the
unused preference.
Regardless, there was more cruft there. GMCP midicontrollables now use
the control surfaces' feedback option.
|
|
|
|
|
|
the grid
|
|
file format (ver 5) rather than the older v3 format
|
|
|
|
requests - the MIDIControllable belongs to the surface code in controllables
|
|
|
|
|
