SaschaFranck

Sorry for the possible confusion, "plain" snapshot coloring is possible, but not when you use them in stomp mode via Command Center (should've said that). The option is there but the LED rings always stay red.

Fwiw, LED rings of switches assignd to Snapshot commands still can't be color coded in 2.91. Not much of an issue, though.

Ok, done. Went great without any glitches, fixes seem to fix exactly what the info page says, tap tempo (my biggest concern) is fine! Have to say that this was a stunningly fast fix, gonna tip my hat at Line 6 for that!

Wow, that was fast! After my grieves with 2.9, color me impressed!

Once it's up and running, I'm not experiencing any of the problems but the tap tempo issue myself, either. But I can 100% reproduce the tuner and volume knob bugs in case I don't wait for a while after booting. This is all fine. I also appreciate (and even praise) Line 6 for adding features for free (and I already love the new Command Center options - too bad there's no live playing for a while, my redesigned patches would make things a lot more fun than it already was). And I also acknowledge that they have quickly approved those bugs and presented a workaround (not for the tap tempo issue, though). Yet, I am still wondering how this could be released. I mean, it took quite a long while since 2.82, I would expect this to be more foolproof. As said before, I have been part of a whole lot of audio software (occasionally hardware, too) betatests, and usually something with such IMO obvious bugs such as in 2.9 wouldn't have been released. The tap tempo issue alone could be considered a shopstopper, the golden rule being that you don't release software with such showstoppers. Fwiw, it's not as if I wouldn't like to give Line 6 and their testers the benefit of the doubt - for example I could perhaps imagine that tap tempo would be working on some people's Helixes. Still, so far nobody has been able to prove that it would work indeed. In fact, I already asked two folks from the german Helix FB group, they also claimed tap tempo would be working fine - but once they really tried, they had to acknowledge that it's not working. Anyhow, as a fix is in the works, I won't bother anyone anymore. I just don't get being accused of whatever it might be for pointing out obvious flaws. And fwiw, releasing such updates IMO isn't much in the interest of Line 6, either.

So, which part of the contradiction between "officially approved issue" and "works" do you not comprehend? I don't know: A) How you came to the conclusion O wouldn't like the Helix. B) How it qualifies as bitterness when you try to pinpoint some bugs in software.

Switches not working anymore, other knobs not working anymore, tuner not working anymore, entire unit freezing in.

Can you prove that?

See, personally, I absolutely treat the Helix as "bought as is". It's exactly why, for a while, the GT-1000 was my preferred choice. But as I had no need to update my setup, I was waiting for 2.8 - which brought certain essential things (for me) to the table so the Helix was it. And I would never complain at all in case 2.82 was the last update the Helix would ever see. I even would have no problems turning back to it should Line 6 not manage to fix 2.9 properly. In other words: My Helix is delivering exactly what was promised and what I need. Sure, in case it was stuck on 2.82, I would likely have a look at the competition one day, but still, I wouldn't complain as I got exactly what I paid for (minus a few bugs fortunately not affecting me much so far, such as corrupted presets). Ok, so much about that, just to make things clear. But now, if you bring up updates and keep telling people the current Helix family hasn't even remotely seen its EOL, the updates you come up with should rather be of decent quality. And given the tons of issues this update has caused for plenty of people (fortunately I'm only affected by the tap tempo bug which isn't essential in these days of non-live-playing), I don't think this is up to whatever Line 6's standards might be (unless they have considerably lowered the bar, which I absolutely doubt). Now, I have no idea what went so wrong (seriously, there's *tons* of complaints around the web, more than with any other update, as far as I remember - and I watched the Helix scene for a whole long time before I purchased mine), but something very clearly did. I mean, the official word by now is "don't touch anything for half a minute after booting to avoid major issues" - just around one day after releasing the update. Seriously, that's pointing to a severe lack of whatever it might be. In a nutshell: No, I don't expect free beer. But in case someone comes up with it, it should rather not be stale.

Apparently not too many people used tap tempo, either.

So, boot times actually got longer with 2.9 as you risk running into some fatal malfunctions in case you operate the thing too early. Yeah well...

Gotta agree here completely. IMO, the entire 2.9 update is a pretty bad affair. I would much rather have Line 6 concentrate on quality control, stability and usability instead of adding nerdy features pretty much nobody is using, such as the Helix being able to work as a keyboard (for which there is almost no reason as there's utlilities converting MIDI messages into keyboard messages, in case you really need that kinda thing).

Well, he's only made 4 posts on this forum, but all of them read as if he was on the Helix team. I guess if he was an imposter, they would be deleted. It'd be great if someone in the knows could shed some light on this. I just made some experiments (using the mouse in HX Edit, as tapping on the unit is messed up...) and can't tell what's actually going on. For instance, I just tapped 3 taps at 90BPM and slowed down considerably with the fourth tap - and yet, the tempo stayed at 90BPM (well, kinda-ish, due to my tapping inaccuracy). My assumption would be, that, in case it's implemented really well, that my last tap was so much out of time that it slipped out of the "set grid" that was established by the first 3 taps. If it was implemented like that, this would help to avoid tempo havoc caused by any accidental taps. Anyway, it's pretty hard (or even impossible) to tell what's going on, especially as I had the occasional glitch with 2.82 already as well. While this is true, apart from the mentioned odd glitch, I usually managed to get it right with 2.82 (well, "right enough" for live at least) but noticed it to be off in 2.9 instantly once the issue was brought up here, causing me to check. I noticed the resulting tempo to be consistently faster than my taps and all further tests have proven that.

Now that you're asking, I'm actually not sure anymore - but I seem to remember the name from somewhere. Also, why would some ordinary user jump in and claim such things? Anyhow, doesn't really matter (I might do some investigation, though, just out of curiositiy) as with 2.9 it's absolutely predictable that the tempo is always higher than what I tap in.

See, this is why I said it was glitchy (in the other thread). I tried exactly what you've suggested and sometimes it really seemed like a proper average tap tempo calculation, sometimes it was way off. However, in general things were just working fine for me - just not with 2.9 anymore. So let's hope there's indeed a hotfix coming soon.

I realized it's a known problem. Some others however don't seem to...

Ah, found it, see the post of Line6Nelson in this thread: You may see my response as well - yes, it's sometimes glitchy, but still, I am always getting faster tempos with 2.9.

According to some Line 6 guy (I don't remember whom it was and can't find a link), tap tempo is supposed to work exactly the same as on Boss units, calculating an average tempo out of the last 4 taps (only in case there are that many taps). I was in doubt about that, but that's what has been said. Anyhow, with 2.9 I am getting faster tempos when using the tap tempo switch all the time, doesn't matter whether I tap more often or not, it's always faster. And it wasn't like that with 2.82.

Of course. Because I simply don't believe it's working correctly anywhere.

Here we go. You can see the differences of the tap results in the Helix display. The delays themselves react accordingly, so there's no need to play through them for this demonstration (if you wanted, I'd do that as well). Fwiw, it's acting like that regardless of which global settings I chose.

Well, the functionality is broken. By now, this is officially approved. No idea how you think you could help me with a function that is officially broken.

No idea how that would help you, but I'll do just that later on.

No, there's absolutely nothing up to me. You don't want to prove the tap tempo function is working properly.

And this is precisely what I'd like to see. End of story.

Fwiw, while free re-ordering of IRs is a welcomed addition, the IR dilemma still isn't adressed. - When you backup a patch, the IR(s) used isn't backed up along with it. No way to keep track of things others than manually exporting it and writing it down. - When you load a patch and the IR is missing, HX Edit is telling you so but offers no hints as far as the IR the patch needs goes, let alone an automatic file system search (which would be the only decent way to fix this once and forever). Really, should be treated exactly the way software samplers are doing it.