View Issue Details

IDProjectCategoryView StatusLast Update
0007741ardourfeaturespublic2024-02-24 00:45
Reportercolinf Assigned Tox42  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionreopened 
Product Version5.X git (version in description) 
Summary0007741: Group gain sharing should never happen for groups where it's not enabled
DescriptionIf I want a group to have gain sharing (either absolute or relative), I'll enable it in the group's properties. If I don't want a group to have gain sharing by default, I certainly don't want it to have gain sharing when I <Shift>+Click on any of the groups faders. There are more use cases for groups without gain sharing than with it, in my experience, especially now that we have VCAs, which do all that group gain sharing could and more.
Additional InformationI have a vague memory of making this report before, but I can't find it now...
TagsNo tags attached.

Relationships

has duplicate 0009641 new Wrong behaviour Shift+Click in groups 
related to 0008910 new Strange inverted behaviour with track groups 
related to 0007449 new shift click fader in group reverses link behavior 

Activities

colinf

2020-01-22 12:34

updater   ~0020925

This still bothers me. I might have just grouped some tracks to record-enable them together more easily, or even just to make them all the same colour - I really never want gain-sharing for such a group, shift pressed or not.

I do find <shift>+click on faders to reset them occasionally useful, but if I accidentally<shift>+click a grouped fader it'll reset all the faders of the group, regardless of what the group is for. Worse, it doesn't even do it consistently: it depends on the setting of the group's 'Relative' gain tick box (which isn't even enabled if 'Gain' is unticked) as to whether the other faders in the group will all reset to 0dB, or keep their gains relative to the 0dB level of the <shift>+clicked fader. Worse still, even if 'Relative' is ticked, faders that would have gone above +6dB are clamped to +6dB, and even the relative balance of the group faders is lost.

bluebones

2020-01-25 13:27

reporter   ~0020930

+1

Would be nice to have the handy shift+click gain reset back affecting just one track, given that Gain is unticked on group settings.

bluebones

2020-01-25 13:39

reporter   ~0020931

I'd add that this happens even with group's side label deactivated, which actually makes me think of it as a bug rather than a feature request.

colinf

2020-01-27 19:30

updater   ~0020937

And it's no less inconsistent when a group has 'gain' sharing enabled: in that case, <shift>+click on a grouped fader resets just that fader to 0dB, except if the group itself is disabled, in which case it resets all the faders, relatively or absolutely according to the 'relative' setting.

colinf

2020-01-27 19:34

updater   ~0020938

I believe that <shift> was originally supposed to invert the enabled status of a group when clicking on elements of tracks with that group, but even that doesn't seem consistent: some mixer strip controls (e.g. record arm) treat <ctrl > in that way instead.

johne53

2022-05-05 09:20

reporter   ~0026433

This relates to a bug we've been discussing on the Mixbus forum. Mixbus has a few problems of its own but AFAICT, when the Shift key is being pressed, neither Mixbus nor Ardour take any notice of a group's Gain Sharing status :-(

Surely this can't be difficult to fix ?

x42

2022-05-21 21:13

administrator   ~0026453

This is intended behavior. Holding down the primary modifier key inverts group behavior: `InverseGroup` (enable disabled groups, disable enabled groups or group-settings)

johne53

2022-05-22 10:46

reporter   ~0026454

Hi Robin - the problem is that different controls exhibit different behaviours. Mixbus has some additional issues (controls on the Mixer don't always behave like they do in the Editor) but let's just concentrate on Ardour for now...

1) Add 2 tracks to a group and then edit the group to remove the gain control.
2) Each fader behaves (correctly) as though it's not part of the group. And using Shift+ inverts that behaviour (correctly, as we now know...)
3) Now try removing some buttons from the group (let's say the Muting button)
4) Each Mute button now behaves (correctly) as if it's not part of the group - BUT... using Shift+ makes no difference (i.e. it doesn't invert the behaviour)

colinf

2022-05-22 13:56

updater   ~0026455

I made a spreadsheet (I know, sorry) enumerating the the <Shift>+click fader behaviour for all the possible states of group enabled/gain sharing/relative to see if it made any more sense seeing it in a table like that. Here it is: is this really all intended behaviour?

colinf

2022-05-22 14:01

updater   ~0026456

Incidentally, there's also this comment in gtk2_ardour/gain_meter.cc:586

        // XXX hack allow to override group
        // (this breaks group'ed shift+click reset)

I'd argue that breaking <shift>+click reset to 0dB is rather a steep price to pay to allow three different ways to override disabling group gain sharing to exist.

colinf

2022-05-22 14:06

updater   ~0026457

Also, it seems perverse to me that a disabled (greyed-out) tick box in the group properties should affect the behaviour of the group.

colinf

2022-05-22 17:58

updater   ~0026458

Attached a (trivial) patch to only allow <shift>+click to disable gain sharing if it's enabled in the active group's properties, and not to enable it if it's disabled. I personally think this is better: if the behaviour of enabling gain sharing in a disabled group is also required I really do believe something rather more clever is required than the current code.
0001-gtk2_ardour-only-allow-shift-click-to-disengage-fade.patch (1,219 bytes)   
From 94ae6480887b66b604aa0a4b14924e0777828fb0 Mon Sep 17 00:00:00 2001
From: Colin Fletcher <colin.m.fletcher@googlemail.com>
Date: Sun, 22 May 2022 18:55:42 +0100
Subject: [PATCH] gtk2_ardour: only allow shift+click to disengage fader from
 group

Don't invert the groups gain sharing setting when the fader is
shift+clicked: only allow shift to disable grouped gain changes when the
group is active.
---
 gtk2_ardour/gain_meter.cc | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/gtk2_ardour/gain_meter.cc b/gtk2_ardour/gain_meter.cc
index 577b5d4009..22e4469aff 100644
--- a/gtk2_ardour/gain_meter.cc
+++ b/gtk2_ardour/gain_meter.cc
@@ -583,11 +583,10 @@ GainMeterBase::fader_moved ()
 			value = gain_adjustment.get_value();
 		}
 
-		// XXX hack allow to override group
-		// (this breaks group'ed  shift+click reset)
+		// XXX hack allow to override group if active
 		if (Keyboard::the_keyboard().key_is_down (GDK_Shift_R)
 				|| Keyboard::the_keyboard().key_is_down (GDK_Shift_L)) {
-			_control->set_value (value, Controllable::InverseGroup);
+			_control->set_value (value, Controllable::NoGroup);
 		} else {
 			_control->set_value (value, Controllable::UseGroup);
 		}
-- 
2.30.2

colinf

2022-07-15 16:41

updater   ~0026505

Updated patch to fix merge conflict after 6089ae93 attached. I still find it hard to believe that the behaviour of <shift>+click on faders of channels in disabled groups without this patch is either intended or desirable.
0001-gtk2_ardour-only-allow-shift-click-to-disengage-fade-2.patch (1,213 bytes)   
From 9cf65b63390a32f770a96fde9436b8d14e41e6b7 Mon Sep 17 00:00:00 2001
From: Colin Fletcher <colin.m.fletcher@googlemail.com>
Date: Fri, 15 Jul 2022 17:35:26 +0100
Subject: [PATCH] gtk2_ardour: only allow shift+click to disengage fader from
 group

Don't invert the group's gain sharing setting when the fader is
shift+clicked: only allow the group override modifier key to disable
grouped gain changes when the group is active, not to enable them when the
group is inactive.
---
 gtk2_ardour/gain_meter.cc | 6 +-----
 1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/gtk2_ardour/gain_meter.cc b/gtk2_ardour/gain_meter.cc
index 5e101dac77..a2cac0f844 100644
--- a/gtk2_ardour/gain_meter.cc
+++ b/gtk2_ardour/gain_meter.cc
@@ -584,11 +584,7 @@ GainMeterBase::fader_moved ()
 		}
 
 		if (Keyboard::the_keyboard().modifier_state() == Keyboard::group_override_modifier ()) {
-			if (Config->get_group_override_inverts ()) {
-				_control->set_value (value, Controllable::InverseGroup);
-			} else {
-				_control->set_value (value, Controllable::NoGroup);
-			}
+			_control->set_value (value, Controllable::NoGroup);
 		} else {
 			_control->set_value (value, Controllable::UseGroup);
 		}
-- 
2.30.2

colinf

2022-07-23 14:58

updater   ~0026519

An alternative approach, if the <Shift> override to enable gain sharing is really deemed more important than <Shift>+click to reset to 0dB could be disabling the reset to 0dB behaviour for grouped tracks. I don't like it, but at least it removes the "Oops, I just set all these faders and I don't know how to put them back" on <Shift>+click behaviour, which was my original motivation for this report.

Alternative hacky patches attached (001-libs-widgets-allow-fader-to-opt-out-of-shift-click-r.patch & 0002-gtk2_ardour-disable-reset-to-default-on-shift-click-.patch) to do this, in case anyone's interested.
0002-gtk2_ardour-disable-reset-to-default-on-shift-click-.patch (1,275 bytes)   
From 53d592b836a649e0312c46a5946b35cf007bf49f Mon Sep 17 00:00:00 2001
From: Colin Fletcher <colin.m.fletcher@googlemail.com>
Date: Sat, 23 Jul 2022 15:43:33 +0100
Subject: [PATCH 2/2] gtk2_ardour: disable "reset to default" on shift-click
 for grouped routes

If a fader of a grouped route is shift-clicked, set its NoResetDefault
tweak bit so that shift only has the effect of "override group". If the
route is not part of a group, ensure the tweak bit is cleared.
---
 gtk2_ardour/gain_meter.cc | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gtk2_ardour/gain_meter.cc b/gtk2_ardour/gain_meter.cc
index 5e101dac77..d4f18de777 100644
--- a/gtk2_ardour/gain_meter.cc
+++ b/gtk2_ardour/gain_meter.cc
@@ -584,6 +584,12 @@ GainMeterBase::fader_moved ()
 		}
 
 		if (Keyboard::the_keyboard().modifier_state() == Keyboard::group_override_modifier ()) {
+			ArdourFader::Tweaks tweaks = gain_slider->tweaks();
+			if (_route->route_group())
+				gain_slider->set_tweaks (ArdourFader::Tweaks(tweaks | ArdourFader::NoResetDefault));
+			else
+				gain_slider->set_tweaks (ArdourFader::Tweaks(tweaks & ~ArdourFader::NoResetDefault));
+
 			if (Config->get_group_override_inverts ()) {
 				_control->set_value (value, Controllable::InverseGroup);
 			} else {
-- 
2.30.2

0001-libs-widgets-allow-fader-to-opt-out-of-shift-click-r.patch (1,553 bytes)   
From 1ca545db5e2a8a4ef858cbb40b4fca56e81334dd Mon Sep 17 00:00:00 2001
From: Colin Fletcher <colin.m.fletcher@googlemail.com>
Date: Sat, 23 Jul 2022 15:40:45 +0100
Subject: [PATCH 1/2] libs/widgets: allow fader to opt out of shift+click
 "reset to default"

Add a tweak value to ArdourFader::Tweaks that will disable the action of
resetting the fader to its default value on shift+click when set.
---
 libs/widgets/ardour_fader.cc        | 3 ++-
 libs/widgets/widgets/ardour_fader.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libs/widgets/ardour_fader.cc b/libs/widgets/ardour_fader.cc
index b414e27883..54e14c9522 100644
--- a/libs/widgets/ardour_fader.cc
+++ b/libs/widgets/ardour_fader.cc
@@ -464,7 +464,8 @@ ArdourFader::on_button_release_event (GdkEventButton* ev)
 				ev_pos = rint(ev_pos);
 
 				if (ev->state & Keyboard::TertiaryModifier) {
-					_adjustment.set_value (_default_value);
+					if (!(tweaks() & NoResetDefault))
+						_adjustment.set_value (_default_value);
 				} else if (ev->state & Keyboard::GainFineScaleModifier) {
 					_adjustment.set_value (_adjustment.get_lower());
 #if 0 // ignore clicks
diff --git a/libs/widgets/widgets/ardour_fader.h b/libs/widgets/widgets/ardour_fader.h
index 31ca47d6c1..9029e5572d 100644
--- a/libs/widgets/widgets/ardour_fader.h
+++ b/libs/widgets/widgets/ardour_fader.h
@@ -49,6 +49,7 @@ public:
 		NoShowUnityLine = 0x1,
 		NoButtonForward = 0x2,
 		NoVerticalScroll = 0x4,
+		NoResetDefault = 0x08,
 	};
 
 	Tweaks tweaks() const { return _tweaks; }
-- 
2.30.2

colinf

2023-12-28 16:07

updater   ~0028439

Now that gain fader adjustments work on all selected tracks, the behaviour is even more confusing, especially since a click in the fader doesn't actually select the track.

Now, <shift>+click on a fader in an inactive group still, adjusts the faders of all tracks in the group, regardless of whether they are selected, but doesn't affect the faders of other selected tracks, whilst adjusting the fader of a selected track in an inactive group adjusts all selected faders.

In my opinion, this was bonkers before, and it's double-plus-bonkers now.

Issue History

Date Modified Username Field Change
2019-03-20 23:22 colinf New Issue
2020-01-22 12:34 colinf Note Added: 0020925
2020-01-25 13:27 bluebones Note Added: 0020930
2020-01-25 13:39 bluebones Note Added: 0020931
2020-01-27 19:30 colinf Note Added: 0020937
2020-01-27 19:34 colinf Note Added: 0020938
2022-05-04 12:34 colinf Relationship added related to 0008910
2022-05-05 09:20 johne53 Note Added: 0026433
2022-05-20 18:14 colinf Relationship added related to 0007449
2022-05-21 21:13 x42 Assigned To => x42
2022-05-21 21:13 x42 Status new => resolved
2022-05-21 21:13 x42 Resolution open => no change required
2022-05-21 21:13 x42 Note Added: 0026453
2022-05-22 10:46 johne53 Note Added: 0026454
2022-05-22 13:56 colinf Note Added: 0026455
2022-05-22 13:56 colinf File Added: grouped-fader-shift-click.ods
2022-05-22 14:01 colinf Note Added: 0026456
2022-05-22 14:06 colinf Note Added: 0026457
2022-05-22 17:58 colinf Note Added: 0026458
2022-05-22 17:58 colinf File Added: 0001-gtk2_ardour-only-allow-shift-click-to-disengage-fade.patch
2022-07-15 16:41 colinf Note Added: 0026505
2022-07-15 16:41 colinf File Added: 0001-gtk2_ardour-only-allow-shift-click-to-disengage-fade-2.patch
2022-07-23 14:58 colinf Note Added: 0026519
2022-07-23 14:58 colinf File Added: 0002-gtk2_ardour-disable-reset-to-default-on-shift-click-.patch
2022-07-23 14:58 colinf File Added: 0001-libs-widgets-allow-fader-to-opt-out-of-shift-click-r.patch
2022-07-23 22:27 colinf Status resolved => feedback
2022-07-23 22:27 colinf Resolution no change required => reopened
2023-12-28 16:07 colinf Note Added: 0028439
2023-12-28 16:07 colinf Status feedback => assigned
2024-02-24 00:45 colinf Relationship added has duplicate 0009641