IdeaScale submissions

[hideout]

So, can someone please explain what's going on with the status of idea submissions? Two of my submissions have been moved to "In Review " and one was moved to "Released" and that one I can't find anymore! What up wid dat?!

[Digital_Igloo]

Basically, I go through every day (or sometimes every two or three days) and change the status. "In Review" means it's been looked at and discussed; "Released" means its already implemented in some fashion.

 

Any submission that's viable and doesn't already exist in our (ridiculously huge) model/feature backlog is added and prioritized. If a submission disappears, it may have simply been merged with a similar idea.

 

There's nothing all that telling or special about IdeaScale. It's just there to help us validate features to the rest of the organization, and of course to help prioritize our backlog.

[Smashcraaft]

Hm. My suspicion from watching the changes was, that most ideas, especially those depending to POD HD, are switched to "in review" as an alias of some kind of virtual trash can, because the switches seem to appear very quickly, even if there are just a few likes ;)

[Digital_Igloo]

Hm. My suspicion from watching the changes was, that most ideas, especially those depending to POD HD, are switched to "in review" as an alias of some kind of virtual trash can, because the switches seem to appear very quickly, even if there are just a few likes ;)

Yep, we review every submission. If you see a bunch of switches, it's because I just logged into IdeaScale. :)

[hideout]

 "Released" means its already implemented in some fashion.

 

 

My idea is sort of kind of implemented but in a kludgy, wholly inelegant way. Easy to implement, not so much. My proposal was a simpler, easier to understand method. 

[Digital_Igloo]

My idea is sort of kind of implemented but in a kludgy, wholly inelegant way. My proposal was a simpler, easier to understand method. 

 

Hi hideout,

 

I didn't see a specific proposal or method as much as a request to make one specific use case—footswitch assignment of path switching—more obvious. Regardless, I've set the idea back to "In Review" and will keep thinking about it. Thanks!

 

Because Helix can do an insane amount of things, we felt it necessary to actively avoid chasing down specific protocols for each of the millions of things users might want to accomplish. To this end, we've distilled footswitch assignment of any signal path item down to one of two extremely fast methods:

 

To assign a footswitch to block bypass in 3 seconds:

1. Select the desired block.
2. Touch and hold the desired footswitch until the dialog appears.
3. Press Knob 6 (OK).

To assign a footswitch to a parameter in 3 seconds (including the A/B split Route To parameter):

1. Select the desired block.
2. Press and hold the desired parameter's knob. Helix jumps to the Controller Assign page for that parameter.
3. Press Knob 6 (Learn Controller) and press the desired footswitch.

Adding a third top-level footswitch assignment protocol (actually it'd have to be a Path 1A/1B, 1A/2A, 1A/2B, 1B/2A, 1B/2B, 2A/2B switch assignment protocol, since Helix has up to four paths) doesn't feel like it fits within the current UI, as preset-level parameters don't really belong on the Home screen unless they're part of a block. It would also need to account for users who don't want a hard path switch—say they'd want to blend in a bit of Path B along with Path A.

 

Perhaps I'm missing something simple that does fit within the current paradigm; we've redesigned parts of Helix a lot.

[hideout]

Thanks, Digital Igloo.

 

I know how to assign blocks and parameters to a footswitch. However, when I'm at the input parameter of say, Path 1, where you can choose "Multi", "Guitar", "Variax", etc or none, I can find no way to assign one of those choices to a footswitch.  It would be nice if you could have each Path switch from "Guitar" in the minimum setting and "None" in the maximum setting via a footswitch.  Path 2 could then be assigned in the reverse order - "None" in the minimum setting and "Guitar" in the maximum setting.  Currently I know of no way to do this.

[Digital_Igloo]

Thanks, Digital Igloo.

 

I know how to assign blocks and parameters to a footswitch. However, when I'm at the input parameter of say, Path 1, where you can choose "Multi", "Guitar", "Variax", etc or none, I can find no way to assign one of those choices to a footswitch.  It would be nice if you could have each Path switch from "Guitar" in the minimum setting and "None" in the maximum setting via a footswitch.  Path 2 could then be assigned in the reverse order - "None" in the minimum setting and "Guitar" in the maximum setting.  Currently I know of no way to do this.

 

Since they're input block types, that would be the same as toggling between Delay types (not that that wouldn't be cool). You can, however, assign an Output or Mixer block Level parameter to a footswitch.

 

The easiest thing to do though is to start with one of the dual tone templates: 8 TEMPLATES > 02C TwoTones A-B (toggle with footswitch) or 02D TwoTones Blend (blend with expression pedal).

[hideout]

Since they're input block types, that would be the same as toggling between Delay types (not that that wouldn't be cool). You can, however, assign an Output or Mixer block Level parameter to a footswitch.

 

The easiest thing to do though is to start with one of the dual tone templates: 8 TEMPLATES > 02C TwoTones A-B (toggle with footswitch) or 02D TwoTones Blend (blend with expression pedal).

 

Assigning an output messes with the reverb tails - cuts them off.  Not cool.

 

Unless I'm mistaken, the Path a/b method can run out of DSP quickly in some scenarios. I want to make it so that each path has as much DSP headroom as possible.

 

I also want it so that the different paths and their signal chains are easy to see.  It looks kinda muddled using the current A/B method.

 

I still don't understand why it would be a problem to have inputs (or delay types as you suggested, for that matter) that are foot switch assignable.

[phil_m]

Assigning an output messes with the reverb tails - cuts them off.  Not cool.

 

Unless I'm mistaken, the Path a/b method can run out of DSP quickly in some scenarios. I want to make it so that each path has as much DSP headroom as possible.

 

I also want it so that the different paths and their signal chains are easy to see.  It looks kinda muddled using the current A/B method.

 

I still don't understand why it would be a problem to have inputs (or delay types as you suggested, for that matter) that are foot switch assignable.

 

If you want to want switch paths using the split block and still maximize DSP usage for both paths, you can have the A/B split in Path 1 and then set the output of path 1A to feed 2A and 1B feed 2B. This will allow you to have blocks spanning both processors.

 

The other way to do it without an actual split block is to just have paths 1 and 2 separate and control the channel volume parameter in each amp block with a footswitch.

[hideout]

If you want to want switch paths using the split block and still maximize DSP usage for both paths, you can have the A/B split in Path 1 and then set the output of path 1A to feed 2A and 1B feed 2B. This will allow you to have blocks spanning both processors.

 

The other way to do it without an actual split block is to just have paths 1 and 2 separate and control the channel volume parameter in each amp block with a footswitch.

Yes I'm sure that would work but all of these suggestions are technically work arounds. My question is this. As capable as the Helix is, why should we have to use work arounds in the first place? Ridiculous!

[phil_m]

Yes I'm sure that would work but all of these suggestions are technically work arounds. My question is this. As capable as the Helix is, why should we have to use work arounds in the first place? Ridiculous!

 

I don't really see them as workarounds. It's just giving you different options to do things.

 

We've been down this path before. Have you actually tried my suggestions? They will work. Even if Line 6 decides to implement your idea, it's going to be awhile. What I'm offering you as solutions will work now. I'm not so sure why it seems to antagonize you so much.

[hideout]

I don't really see them as workarounds. It's just giving you different options to do things.

 

We've been down this path before. Have you actually tried my suggestions? They will work.

Yes. Thank you. I did try your suggestions and yes they work. Implementing them however has only cemented my opinion that they are in fact work arounds and a completely inelegant and needlessly complicated way to achieve a rather simple objective.

[Digital_Igloo]

FWIW, the ability to mute input blocks seems kinda scary—feels too easy for someone to inadvertently lose their signal. For the same reason, we omitted the ability to select "None" as an input for 1A or 1B. At least when assigning footswitches to processing blocks and/or parameters, the user is doing something deliberate.

 

Doesn't solve the issue of more obvious path switching tho'. Still thinking...

 

By the way, these are the types of conversations I like most. :)

[hideout]

FWIW, the ability to mute input blocks seems kinda scary—feels too easy for someone to inadvertently lose their signal. For the same reason, we omitted the ability to select "None" as an input for 1A or 1B. At least when assigning footswitches to processing blocks and/or parameters, the user is doing something deliberate.

 

Doesn't solve the issue of more obvious path switching tho'. Still thinking...

 

By the way, these are the types of conversations I like most. :)

I think that people are smart enough and will figure it out and I think you can make it so that you have to intentionally mute an input. Speaking of muting, I've found a little trap in the implementation of the sends and returns. Those connections are not "normalled" like in patch bays. Thus, if you have a return active and nothing's connected there, you get No Signal. Lol

Well, OK, you do if you have the mix set at 50% or less but I always have mine set to 100% so that there are no phasing issues.

[Digital_Igloo]

Speaking of muting, I've found a little trap in the implementation of the sends and returns. Those connections are not "normalled" like in patch bays. Thus, if you have a return active and nothing's connected there, you get No Signal. Lol

Well, OK, you do if you have the mix set at 50% or less but I always have mine set to 100% so that there are no phasing issues.

 

That's by design. FX Loop blocks' Mix parameters default to 100%, which yes, would mute any signal if a pedal's not connected. The Returns' Mix parameters default to 50%.

[hideout]

That's by design. FX Loop blocks' Mix parameters default to 100%, which yes, would mute any signal if a pedal's not connected. The Returns' Mix parameters default to 50%.

 

Yup.  I get it.

[ChubbyJerk]

It's good to know the ideas all get looked at regardless of voting. Line 6 has a lot of knowledge that we don't concerning market trends and feasibility and a dozen other factors beyond the "hey that's cool" factor that the average user (including myself) might vote on.

 

A couple of my ideas got moved to Review status before they had a chance to go far either way (one was definitely going down anyway, but still), and I was worried they'd just float off into the void. They're both long-shots anyway, but still...maybe some day...

 

Anyway, it's great of you guys to do that. I know it's a lot of work to sift through them all, but I think the direct connection between Line 6 and the customers is a very cool thing that not many companies would be willing to tackle.