Wish Channel Groups and Bypass Groups

[TubThumper74]

Appreciate your support for this idea, but no, Line 6 snapshots aren't really the same.

I was using your example of:

• Turning on a drive block that's louder than the original signal, so it pushes the amp, but that gets a lot louder.
  I'd like to turn on a volume or EQ block after the amp at the same time, to compensate.
  I want this all day every day.

This can be done with snapshots in any HX based product and what I was referring to. Any expanded control options, however, are always welcome!

 

[Seven2Eleven]

I was using your example of:

• Turning on a drive block that's louder than the original signal, so it pushes the amp, but that gets a lot louder.
  I'd like to turn on a volume or EQ block after the amp at the same time, to compensate.
  I want this all day every day.

This can be done with snapshots in any HX based product and what I was referring to. Any expanded control options, however, are always welcome!

Snapshots in the Helix are analogues to scenes in Fractal. Scenes in Fractal can do what @Dave Merrill was describing. But the point of this request is to be able to do that INDEPENDENT of scenes and have a single instant access switch that can turn on and off multiple blocks.

The Helix CAN do that because of the way it handles bypass assignments. You can just generically assign bypass states for multiple blocks to one switch.

You CAN also do that with Fractal using control switches. But you only have 6 of them and they're limiting in other ways, most significantly that they can't control channels. The point of this request is to have this functionality as one of the basic FC options.

 

[Seven2Eleven]

Just revisiting this thread and I was wondering something…

@Dave Merrill, the way you theorized this working would these bypass groups be able to have blocks in opposite states like control switches can? Can you have one block engage while another bypasses in the same group?

 

[Amaranthine3]

+1

 

[Dave Merrill]

Just revisiting this thread and I was wondering something…

@Dave Merrill, the way you theorized this working would these bypass groups be able to have blocks in opposite states like control switches can? Can you have one block engage while another bypasses in the same group?

EDIT: I think this whole post was wrong-headed. I'll leave it here for possible discussion, but see my next post for what I'm pretty sure it's a better way to think about it. I don't have time to get that together right now, but i will when i can.
=================
Hmmm, interesting. I guess there are a couple of possibilities.

Simplest one is no, the same group action is done to all blocks assigned to that group. That's what i had in mind when i had this idea.

Note that if the action is toggle, it would toggle the state of each block from whatever it was. Say drive 1 is on and drive 2 is off, and both are in the same bypass group. Toggling that group would flip both blocks' bypass state, turning drive 1 off and 2 on.

Another possibility is that when you assign a block to a bypass group, there's an Invert checkbox, which inverts the sense of the group action for that block. But how does that work if the switch action is toggle?

This also brings up some other interesting questions:

• If a block is in a bypass group, it that all that controls whether it's bypassed or not, like with controllers? Does it override the state saved in each scene?
• That doesn't make sense for the switch action of toggle. What state is the block in when the preset or scene loads?
• We could say that if the group a block is in is controlled by a group toggle switch, then it honors its state saved in each preset, otherwise it's controlled only by that bypass group.
• That doesn't really work though, because multiple switches could control the same group, potentially with any mix of bypass, enable, and toggle actions.
• What happens if you trigger some bypass groups, then save the preset? Do the current states of those blocks get saved in the scenes? It would be weird if they didn't i think, but that says scene state DOES matter.

Unless I'm missing something, these are non-trivial questions.

I'm disappointed. I thought this wish was pretty simple to understand, and hopefully not that hard to implement.

But from here, it seems like there are a number of unresolved issues with no obvious right answers.

 

[Seven2Eleven]

Hmmm, interesting. I guess there are a couple of possibilities.

Simplest one is no, the same group action is done to all blocks assigned to that group. That's what i had in mind when i had this idea.

Note that if the action is toggle, it would toggle the state of each block from whatever it was. Say drive 1 is on and drive 2 is off, and both are in the same bypass group. Toggling that group would flip both blocks' bypass state, turning drive 1 off and 2 on.

Another possibility is that when you assign a block to a bypass group, there's an Invert checkbox, which inverts the sense of the group action for that block. But how does that work if the switch action is toggle?

This also brings up some other interesting questions:

• If a block is in a bypass group, it that all that controls whether it's bypassed or not, like with controllers? Does it override the state saved in each scene?
• That doesn't make sense for the switch action of toggle. What state is the block in when the preset or scene loads?
• We could say that if the group a block is in is controlled by a group toggle switch, then it honors its state saved in each preset, otherwise it's controlled only by that bypass group.
• That doesn't really work though, because multiple switches could control the same group, potentially with any mix of bypass, enable, and toggle actions.
• What happens if you trigger some bypass groups, then save the preset? Do the current states of those blocks get saved in the scenes? It would be weird if they didn't i think, but that says scene state DOES matter.

Unless I'm missing something, these are non-trivial questions.

I'm disappointed. I thought this wish was pretty simple to understand, and hopefully not that hard to implement.

But from here, it seems like there are a number of unresolved issues with no obvious right answers.

Yeah these are interesting points.

This is me thinking out loud but this is how I imagine it:

Every block now has an option to also assign it to a bypass group like you said. The state the block is in when you assign it to the group is how it is recalled when the whole group is recalled via the group bypass foot switch action.

So say I have a scene where I have both a drive and delay engaged but then those blocks are assigned to a group where the drive is on but the delay is off. Recalling that scene works as usual but then recalling the group with a foot switch action will set those blocks to their initial states in the group (Drive on, Delay off in this case). Hitting the group foot switch again would then bypass the drive and engage the delay. I realize that there might be some scenarios where you would have to hit the group foot switch twice to get to the intended state but other than that, is there anything else I'm missing?

 

[Dave Merrill]

EDIT: I think this whole post was wrong-headed. I'll leave it here for possible discussion, but see my next post for what I'm pretty sure it's a better way to think about it. I don't have time to get that together right now, but i will when i can.

Apologies for not coming back to this sooner, but here's what i think makes the most sense:

Channel groups and bypass groups aren't presets you can recall, like scenes are. They're just a way to make the action assigned to a switch affect multiple blocks at once, really simple.

BYPASS just toggles the affected blocks on and off, from whatever state they're in. Say a drive, a reverb, and a delay are in the same bypass group, and reverb is initially on. For a solo, you toggle that group. That turns reverb off, and drive and delay on.

CHANNEL SELECT sets all affected blocks to that configured channel.
CHANNEL TOGGLE toggles the channel of all affected blocks between the configured primary and secondary channels.
CHANNEL INCREMENT/DECREMENT changes the channel of all affected blocks according to the configured increment/decrement, wrap, and upper and lower limit settings.

Note that another switch could toggle one of those blocks on or off or change its channel, and scenes inherently recall the bypass states and channels of all blocks that don't have scene ignore turned on. None of that changes what group actions do, just the initial bypass state and initial channel the action starts from.

There's nothing complex or existentially unfeasible about this.

It's not as flexible as the ability to program a single switch to do any arbitrary set of multiple actions on arbitrary sets of blocks, but way easier to set up and use. It leverages how footswitches currently work, to affect multiple blocks at once.

 

[Dave Merrill]

Just to say it, I really hope the simplicity and nothing-new-ness of this idea makes it appealing enough and easy enough to implement that it actually happens.

 

[Seven2Eleven]

Apologies for not coming back to this sooner, but here's what i think makes the most sense:

Channel groups and bypass groups aren't presets you can recall, like scenes are. They're just a way to make the action assigned to a switch affect multiple blocks at once, really simple.

BYPASS just toggles the affected blocks on and off, from whatever state they're in. Say a drive, a reverb, and a delay are in the same bypass group, and reverb is initially on. For a solo, you toggle that group. That turns reverb off, and drive and delay on.

CHANNEL SELECT sets all affected blocks to that configured channel.
CHANNEL TOGGLE toggles the channel of all affected blocks between the configured primary and secondary channels.
CHANNEL INCREMENT/DECREMENT changes the channel of all affected blocks according to the configured increment/decrement, wrap, and upper and lower limit settings.

Note that another switch could toggle one of those blocks on or off or change its channel, and scenes inherently recall the bypass states and channels of all blocks that don't have scene ignore turned on. None of that changes what group actions do, just the initial bypass state and initial channel the action starts from.

There's nothing complex or existentially unfeasible about this.

It's not as flexible as the ability to program a single switch to do any arbitrary set of multiple actions on arbitrary sets of blocks, but way easier to set up and use. It leverages how footswitches currently work, to affect multiple blocks at once.

This seems simple enough. However, with the bypasses only as toggles, that would mean that you could possible set the blocks in the group “out of sync”, right? Again, using my example of you want a drive and delay to come on and off as group, you have one scene where both the effects are on, you also have a group toggle switch for them in one of your layouts, you also have stand alone block bypass switches. Lets say you’re in that scene and it loads with drive and delay on but then you manually turn off just the delay with the delay bypass switch, and then you hit be group toggle switch, they would then flip flop (drive off, delay on, drive on, delay off). That might not be the intended behavior but then it could be just reset when you refresh the scene (assuming you have scenes set to discard changes)

 

[Dave Merrill]

This seems simple enough. However, with the bypasses only as toggles, that would mean that you could possible set the blocks in the group “out of sync”, right? Again, using my example of you want a drive and delay to come on and off as group, you have one scene where both the effects are on, you also have a group toggle switch for them in one of your layouts, you also have stand alone block bypass switches. Lets say you’re in that scene and it loads with drive and delay on but then you manually turn off just the delay with the delay bypass switch, and then you hit be group toggle switch, they would then flip flop (drive off, delay on, drive on, delay off). That might not be the intended behavior but then it could be just reset when you refresh the scene (assuming you have scenes set to discard changes)

I get what you're saying about the bypass actions for the different blocks in a group getting out of sync. The same thing could happen with channel actions.

Configuring a switch to perform an action on a group doesn't change the action, just the target(s) of whatever action the switch is configured to do. That's why i think this would be fairly easy to implement - there isn't really anything new here.

As it stands, without any of this, the bypass action is inherently a toggle, starting from the current state of the block. Recall a preset with drive 1 off, and a bypass switch will turn it on, recall one with drive 1 on, and the same switch will turn it off, with no configuration changes. It's a simple toggle.

If the same switch controls a group containing multiple blocks, as proposed it would just toggle each of them from their current state. Still simple, but can't be made to always turn drive 1 and delay 1 both on, unless they both start turned off.

What it seems like you're asking for is that the group itself have a state, and that's what pressing a switch assigned to a bypass group toggles, not actual blocks. You'd also have to be able to set each block in the group to follow that state or its inverse, ie turn some off and some on, or purely toggle from its current state..

There are other complications too.

• The Axe would have to track the state of the 15 bypass groups
• What state does the group start in?
• Does that have any effect on the blocks in the group?
• Does it revert to that state when you load a preset? A scene?
• How does this work for channel groups? Channel switch actions can already be configured go to a specific channel, regardless of the block's current channel, but that's only really useful if you have multiple switches, each going to different channels.

Anyway, all of that seems way more complicated than the original proposal, more of a change, and harder to implement, to configure, and to operate in the heat of battle. If it was up to me, I'd vote for the original idea instead.

 

[Seven2Eleven]

I get what you're saying about the bypass actions for the different blocks in a group getting out of sync. The same thing could happen with channel actions.

Configuring a switch to perform an action on a group doesn't change the action, just the target(s) of whatever action the switch is configured to do. That's why i think this would be fairly easy to implement - there isn't really anything new here.

As it stands, the bypass action is inherently a toggle, starting from the current state of the block. Recall a preset with drive 1 off, and a bypass switch will turn it on, recall one with drive 1 on, and the same switch will turn it off, with no configuration changes. It's a simple toggle.

If the same switch controls a group containing multiple blocks, as proposed it would just toggle each of them from their current state. Still simple, but can't be made to always turn drive 1 and delay 1 both on, unless they both start turned off.

What it seems like you're asking for is that the group itself have a state, and that's what pressing a switch assigned to a bypass group toggles, not actual blocks. You'd also have to be able to set each block in the group to follow that state or its inverse, ie turn some off and some on, or purely toggle from its current state..

There are other complications too.

• The Axe would have to track the state of the 15 bypass groups
• What state does the group start in?
• Does that have any effect on the blocks in the group?
• Does it revert to that state when you load a preset? A scene?
• He does this work for channel groups? Channel switch actions can already be configured go to a specific channel, regardless of the block's current channel, but that's only really useful if you have multiple switches, each going to different channels.

Anyway, all of that seems way more complicated than the original proposal, more of a change, and harder to implement, to configure, and to operate in the heat of battle. If it was up to me, I'd vote for the original idea instead.

I get it but I think I’d fine with just being a simple toggle like you described. +1 again for all the thought you’ve put into the idea

 

[skolacki]

I wish switches could control multiple effects so this idea is right up my alley. Another thing I wish for is basic logic functions for switches. Eg my drive is engaged but if I hit the control switch for the amp boost I would like the same switch to turn off the drive only if the drive is on. And vice versa. Same some stomping.

 

[Dave Merrill]

I wish switches could control multiple effects so this idea is right up my alley. Another thing I wish for is basic logic functions for switches. Eg my drive is engaged but if I hit the control switch for the amp boost I would like the same switch to turn off the drive only if the drive is on. And vice versa. Same some stomping.

I get what you're saying, but a generic "logic" engine for interactions between switches seems like a tall order. Expressions, math functions, parentheses, yadda.

If it was different in every preset or scene it'd be pretty hard to deal with live too. Job 1 is always that you know which switch to press for the action you want, and when you step on a switch you get what you think you're going to get.

Can the RJM controllers do things like that?

 

[biskitboy]

Ok, tell me what is wrong with this idea.

I believe a simple change/addition to the scene ignore logic would address a significant portion of use cases. Make the scene ignore feature bound to the actual block itself and not the channel (or add a flag as an option). Scene Ignore will now ignore any block changes when transitioning to the specific scene rather than a specific channel ignored across all scenes.

For example, if I have scene 1 with amp/cab/drive set as scene ignore then all other blocks in this scene change their bypass/channel state during scene activation. Rinse and repeat anyway you want for all other scenes. Best of all, you can configure a scene to control ALL blocks too by not having any blocks set with ignore. Mix/Match to your hearts content.

If this existed, I'd use the first 3 scenes to ignore all my wet blocks thereby controlling my dry tone. And the last 5 scenes set to ignore my dry blocks thereby controlling the wet.

When switching to a new preset, it still behaves the same. Whatever is set for the default scene is the starting point for all blocks.

 

[blaggers]

Great Idea!

 

[spanish_cowboy]

Can we bump this? Dear Fractal, this seems like an awesome idea!