Assign multiple blocks to one automation Switch

[kronda]

Hi Guys,

 

so I noticed I cannot assign multiple blocks to one automation Switch to toggle multiple blocks at once by a single automation lane (in Cubase in my case). It's even mentioned in the manual so I get that it's intentional. Could anybody explain why? It would directly correspond to how Helix Floor footswitches work so I'm a bit puzzled.

 

I would often use this feature because whenever I start automating I feel I'd like to make that change more pronounced (say switch on drive and mod and delay at the same time for a solo). Currently I end up with multiple automation lanes having exactly the same shape just to control 2 or more block toggles (or min-max parameter value changes) at exactly the same time. I guess I should use snapshots but I always start with a simple one block switch and then just want to add 1 or 2 more blocks to the same switch so it's not convenient to change the lane in Cubase...

 

Just wondering, I can live with it, just this seems like an inconsistency in otherwise perfect system.

 

Thanks for any opinions.

[soundog]

In Logic Pro (my DAW), a user normally assigns a single "thing" (plug-in parameter, volume, pan, send, etc) to a single automation lane. It keeps things more predictable and manageable. I imagine its the same in Cubase, unless Cubase lets you create macros to group automations under a single control. Snapshots are really the best thing to use for what you want to do: if you add 1 or 2 more blocks later, edit your HXN snapshot accordingly, and you shouldn't have to change the Cubase snapshot automation.

 

Another option to play with would be MIDI control — you might be able to assign a MIDI control to multiple "things" in Cubase, and use MIDI to control Helix (now that HXN supports MIDI control).

[kronda]

On 7/14/2018 at 8:39 PM, soundog said:

In Logic Pro (my DAW), a user normally assigns a single "thing" (plug-in parameter, volume, pan, send, etc) to a single automation lane. It keeps things more predictable and manageable. I imagine its the same in Cubase, unless Cubase lets you create macros to group automations under a single control. Snapshots are really the best thing to use for what you want to do: if you add 1 or 2 more blocks later, edit your HXN snapshot accordingly, and you shouldn't have to change the Cubase snapshot automation.

 

Another option to play with would be MIDI control — you might be able to assign a MIDI control to multiple "things" in Cubase, and use MIDI to control Helix (now that HXN supports MIDI control).

 

Thanks for your reply but that's not what I'm asking about. Of course that a single automation lane in any DAW will usually control only a single parameter. But in case of Helix Native this parameter to control is an abstract Switch or Knob. And if you look automating, say,  Switch 1 as automatically pressing Footswitch 1 on Helix Floor that you can imagine that multiple actual block toggles could be assigned to Switch 1 similarly as multiple actual block toggles could be assigned to Switch 1 in Native.

 

My question is why did Line 6 resort to this indirect parameter automation while not allowing to assign multiple actual parameters to individual Switch X and Knob X abstract controllers? Rather then exposing all the actual parameters directly (like Amp [Slot A1-3 Drive, Reverb [Slot A2-6] Mix etc)? I guess it's kind of easier to like this, otherwise finding the right parameters could be a nightmare. I would just love if they made that one more step and allow multiple actual parameters assigned to individual abstract controllers...

 

I guess IdeaScale is the only way to get this noticed by Line6.

[soundog]

Snapshots or MIDI control will do what you want to do. Or maybe I still don't understand what you want to do....

 

¯\_(ツ)_/¯ 

[kronda]

I'm not asking how to do something, just why some feature in Native is limited the way it is while it would make perfect sense (to me) to implement it differently. Doesn't matter, perhaps Line 6 will extend this functionality in a future version.