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.
This reverts commit b3722f7063.
In some cases ardour shows context-menu on right-mouse-button
release. In this case selecting a menu-entry should happen
with the left-mouse button (or any button?!)
Using ev->button is only correct if the menu is temporary and only
visible while the button is held, button release then activates the
menu-item.
This needs further work, in some cases allowing any button (0) to work
makes sense and overall consistency needs to be improved.
Different places use different strategies for context-menus which
don't always match the button used in the event-handler.
This is a hotfix (to make TAV context menus work again with left-click)
Tentative solution. Eventually the gain_adjustment should be moved
into the PixFader or SliderController and a dedicated API
should replace gain_adjustment.signal_value_changed()
Due to LevelMeterVBox : public LevelMeterBase, public Gtk::VBox;
LevelMeterBase::get_type() overloads Gtk::Widget::get_type(),
Glib::Object::get_type(), Atk::Implementor::get_type() etc..
Besides Ardour-style prefers not to use get_...()
Remove the LocaleGuard so that the value of LC_NUMERIC is that of the users
locale and sscanf will parse the string correctly. For instance, with a locale
like nl_NL or fr_FR where the decimal point is different than the "C" locale,
only the number up to the decimal point will be parsed by sscanf and input
values will be rounded down.
