smythejmd

Actually, your analogy involved a hardware change. Mine did not, so you support my point in your last response. You do realize that your explanation could be used to used to rationalize away any bug as part of a "not completely developed system"? Your argument has bothered me enough as I asked my fellow software r&d co-workers their opinion on your argument, and no one agreed. Unanimously, it was considered a defect.

Actually, I'm coming to it from the point that everything is built together now. The fact that at some point it was not is irrelevant to a new user. Just update my example that a software update allowed the user to access internet TV. Everything else stays the same. Note, however, that is still irrelevant to the new user.

The analogy is off. Consider that the internet receiver is built into the TV and used the same remote. Imagine that you can change the volume when watching normal TV and when watching internet tv. However, when you switch from normal TV to internet TV and you haven't set the volume to the default 20db before switching, the volume buttons stop working until you press a variety of buttons or plug a cord into the back of your TV. Note that when switching to DVD, you don't have to do any of this to have the volume buttons work normally.

Anyways, I'm glad there is at least some sort of workaround. I'm going to get back to building a pedalboard case for my Helix. I'll leave the thread to other people.

I'll have to link to the facebook post with the video. The issue is not what you described, nor do those workarounds help, since you are suggesting is completely abandoning use of the toe switch. The problem is not limited to wah and volume blocks. The issue is that snapshots do track bypass states of blocks but *NOT* which controller the expression is assigned to (based on toggling the toe switch), which leads them to be out of sync, requiring workarounds to get them back in sync, a dummy plug, or simply abandoning the toe switch altogether. If you don't have the issue, great. If you don't mind tap dancing or the available workarounds (or that workarounds are required), great. If you were pessimistic and expected that the two issues wouldn't be properly integrated, and you're fine with that, great. However, many of us are not in the same boat as you.

Apparently, we are equally anal and will simply continue to disagree. I think you are using "expected" in a way that isn't how I used it, nor is it consistent with an User Experience standard usage; I would "expect" that if they messed up integrating the expression controller toggling with snapshots, then this would be the issue, but that is just a bug expectation, not a User Experience expectation of proper behavior. The fact that people were surprised that the toggle state could go out of sync seems to indicate people were not "expecting" it. I have a feeling actually that you guys aren't getting the issue. I posted a video on FB, and Chad as well as others immediately suggested to do a 9+10 reset, because they immediately interpreted it as buggy behavior.

I'd also like to confirm that Tal's shorted plug workaround works for my use case. However, the toe switch now disabled and enables all volume and gain blocks even when not assigned.

I agree, you can argue semantics all you want on whether it meets someone's definition of a bug, but anyone who has experienced it would agree it's undesirable and unexpected. If they dont, I think they misunderstand the issue.

Actually, what you described would qualify as a bug in the software dev world. When you make changes and it introduces unexpected and undesirable behavior, that is a kind of software bug. I've introduced and fixed a fair share of that kind at my work. Perhaps it's not in the same vein as the others that are talked about, but it's still a bug.

Zooey, that doesn't fix this, unfortunately. Hollis, I'm not sure how that solves the issue.

Simple. The snapshot saves what the toggle has switched to. The same thing it does for presets.

robbie, I'm also a fan of autoengage type wahs. I'm in the same situation as you.

I'm not trying to dog you, but I can't think of a scenario in which getting out of sync would be intentionally designed into it, especially since the behavior isn't there when switching presets. The inconsistency, lack of a justifying scenario, and going against expected behavior all are generally indications that something is a QED bug and not an intentional feature. Unless Line 6 tells us that they intentionally wanted this, all indications point to a software bug, which I have no doubt which they can and will fix easily. In the meantime I'll try the goofy plug workaround.

@phil_m, that's like asking why you wouldn't manually switch off all your effects in manual mode before switching snapshots. Same answer.

Sorry, @phil_m, as a software dev, the way you are defending it to me seems to be reationalizing a defect. Look, if other devices with a similar expression and toe switch setup can switch presets without having issues, then Helix should be able to, as well, using similar logic. I do software research and development for a living--the logic involved is not as difficult as you make it out to be. I agree with everybody else. The workarounds are goofy, and given that the workarounds are consistent, automating them throughs settings would be trivial.