This fixes an issue where brining up a menu can directly activate an
action in the menu. Notably on macOS.
Nathan reports that this may also address #9515
Note: mac touchpads are not affected since right-click there is
effectively a "press and hold".
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.
When switching the Mixer to show sends, using _amp as
intermediate for automation is not correct.
The control is not owned by the amp.
The same is true for VCAs, prefer the control (see 8400ebd175)
After session load, the meter numerics were always visible,
regardless of strip width.
MixerStrip::set_stuff_from_route() and MixerStrip::set_width_enum()
are called before Mixer UI is realized and calls show_all().
Copyright-holder and year information is extracted from git log.
git history begins in 2005. So (C) from 1998..2005 is lost. Also some
(C) assignment of commits where the committer didn't use --author.
I'm not sure why exactly but at this line in 'GainMeter::set_controls ()' :-
model_connections, invalidator (*this), boost::bind (&GainMeter::redraw_metrics, this), gui_context()
MSVC will not allow us to pass a base class function to boost::bind(). I tried explicitly specifying the base class and I also tried making the function public / making it virtual etc but the only thing which works is to implement a derived function.
It's somehow related to changing the signal from 'TypeChanged' to 'MeterTypeChanged' but I don't entirely understand why... :-(
This removes all additional GUI side meter-type state.
The route's meter-processors is now responsible for providing
the type.
meter-type is now implicit for GainMeter, LevelMeter used by
meter-strips and mixer-strips.
74c986534b changes the semantics of fader-flags:
NoVerticalScroll was "ignore vertical scroll for horizontal faders".
Now the flag ignores all vertical scrolling.
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
Depend on Changed() signals alone, which are usually much less frequent
than rapid-timer events.
As side-effect we now need to make the widgets insensitive when
playing automation. Previously the user could not change the value because
the Timer periodically reset it.
Trim automation is planned via SlavableAC as normal AutomationMode.
Some of this code have a revival (a special "Trim+Preview" state
before merging Automation but that has to be more general than Pan & Gain.