Helix Bug Reports

[PeterHamm]

I connected the Helix to the PC, opened the Updater 1.11 and launched the 2.30 update. After reaching 20% of the download everything freezed

 

I saw this a lot on early beta builds. Try this. Download the file rather than letting the updater do it, and then use "local file" to install.

 

For me, that always did the trick, although I haven't experienced this in over a year I don't think.

[Marrissey]

Try using a different USB port if possible. This actually seems to be the fix for this more often than not.

Already tried but it is freezed in that screenshot I posted...even if I press buttons 9 and 10 it doesn't reset

[jbuhajla]

If you are using a desktop PC, use one of the USB ports on the back of the tower. If using a laptop, try a different port. You may have to do a factory reset (hold down FS 9/10 while powering up) if the unit no longer boots up correctly now. Then you can try the update again using a different USB port. 

[Marrissey]

I already tried the reboot with the 9-10 button but doesn't work

[HonestOpinion]

You don't have to change tabs... You just right click on the parameter value from the Edit screen and the controller menu pops up.

 

Great tip, thanks!

[Marrissey]

I solved the problem. I restarted the Helix holding the 6 and 12 buttons. It entered in update mode and the PC recognized it again

[EricRenner]

Editing a patch the display went black. It was still "lit" but the display was empty and hence, black. A reboot seemed ok have fixed the issue.

 

I did have the helix on for quite a long time. Maybe four or five hours. But it wasn't hot. Wasn't connected to the PC. And I'm on the latest firmware.

[JohntheSavage]

Okay, so... Every once in a while, somewhat randomly it would seem, when I boot up the Helix, one of the footswitches (it always seems to be switch 4 in my case) has the state of its LED reversed: i.e. the patch will have been saved with the effect bypassed and the light off, but the Helix will boot up with the effect bypassed and the light on... Why?  It doesn't seem to matter how many times I re-save the patch, and sometimes I can go weeks without seeing this bug at all, but then I turn on the Helix one day and suddenly the state of the LED is reversed again.  How can that be?  I can see if it happened every single time I rebooted the box, but why randomly?

 

About the only insight I can offer, in hopes of narrowing it down, is that the switch is assigned to multiple blocks; some of which start on and get turned off, and others start off and get turned on with that same switch.  Is the Helix getting confused?  Are other parameters randomly reverting to previously saved states without me knowing?

 

I've had this happen in the past, but only after updating the firmware and rebuilding patches.  And I did recently updated to 2.30.  But this is the first time that the issue has persisted afterward, despite re-saving the patch several times.  Anyone?

 

Cheers!

[PeterHamm]

Okay, so... Every once in a while, somewhat randomly it would seem, when I boot up the Helix, one of the footswitches (it always seems to be switch 4 in my case) has the state of its LED reversed: i.e. the patch will have been saved with the effect bypassed and the light off, but the Helix will boot up with the effect bypassed and the light on... Why?  It doesn't seem to matter how many times I re-save the patch, and sometimes I can go weeks without seeing this bug at all, but then I turn on the Helix one day and suddenly the state of the LED is reversed again.  How can that be?  I can see if it happened every single time I rebooted the box, but why randomly?

 

About the only insight I can offer, in hopes of narrowing it down, is that the switch is assigned to multiple blocks; some of which start on and get turned off, and others start off and get turned on with that same switch.  Is the Helix getting confused?  Are other parameters randomly reverting to previously saved states without me knowing?

 

I've had this happen in the past, but only after updating the firmware and rebuilding patches.  And I did recently updated to 2.30.  But this is the first time that the issue has persisted afterward, despite re-saving the patch several times.  Anyone?

 

Cheers!

 

Yup, I've seen this, but not lately.

 

Here's a thing to try.

 

After fixing the issue, save the patch to a different location and then back again.

[JohntheSavage]

Yup, I've seen this, but not lately.

 

Here's a thing to try.

 

After fixing the issue, save the patch to a different location and then back again.

 

I have to move some patches around this week anyway, so I'll try that (fingers crossed).  Thanks for the advice, Peter, much appreciated.

 

Cheers!

[Orb8]

Just recently bought my Helix and am enjoying it  :) 

 

As soon as it arrived I updated the firmware to 2.30, then after the flash I rebooted it. It seemed to lock up & didn't reboot so after a couple of minutes I turned it off

and on again and it fired up normally with the new firmware installed. I didn't think much of it but a couple of times now the display has frozen on boot, so I

have to turn off and on again, after which it responds normally.

 

Is this a known issue?

[phil_m]

Just recently bought my Helix and am enjoying it :)

 

As soon as it arrived I updated the firmware to 2.30, then after the flash I rebooted it. It seemed to lock up & didn't reboot so after a couple of minutes I turned it off

and on again and it fired up normally with the new firmware installed. I didn't think much of it but a couple of times now the display has frozen on boot, so I

have to turn off and on again, after which it responds normally.

 

Is this a known issue?

I can't say I've seen this sort of thing being reported...

 

Since you have a new unit, I'd recommend doing a factory reset if you haven't. Hold down footswitches 9 and 10 while powering up, and that will reset everything. If you've created any presets that you want to keep, make sure your back them up with HX Edit prior to doing the reset procedure.

 

Out of curiosity, have you happened to import any third party presets since you've been using your LT?

[Orb8]

I can't say I've seen this sort of thing being reported...

 

Since you have a new unit, I'd recommend doing a factory reset if you haven't. Hold down footswitches 9 and 10 while powering up, and that will reset everything. If you've created any presets that you want to keep, make sure your back them up with HX Edit prior to doing the reset procedure.

 

Out of curiosity, have you happened to import any third party presets since you've been using your LT?

Thanks for the response.. Yes I've tried the reset procedure.

 

And yes I've purchased the Fremen Big Pack & Add On pack.. However these weren't installed on initial boot failure after the firmware was

updated. So I'm guessing whatever it is, is either a glitch in the factory firmware/software? Otherwise than the very odd time when it freezes on boot the Helix functions perfectly.

[JohntheSavage]

Just recently bought my Helix and am enjoying it  :)

 

As soon as it arrived I updated the firmware to 2.30, then after the flash I rebooted it. It seemed to lock up & didn't reboot so after a couple of minutes I turned it off

and on again and it fired up normally with the new firmware installed. I didn't think much of it but a couple of times now the display has frozen on boot, so I

have to turn off and on again, after which it responds normally.

 

Is this a known issue?

 

I've had my Helix freeze up on me like this.  Granted, it has only happened a couple times, and I was on an earlier firmware: 2.21 I think, or maybe it was 2.12... I don't know, I'm dyslexic (smirk).  Anyway, I haven't had it happen on 2.30 yet, but if it continues to freeze on boot-up, do keep us posted.  And of course, contact support.  Just know that you're not alone (wink).

 

Cheers!

[Orb8]

Thanks John. That's good to know.

 

Cheers

[donrock1]

Hello!

I'd like to report an issue with the Arbitrator Fuzz block in the new 2.30.0 firmware. When I place it in a path everything is fine as long the fuzz is on, when I turn it off, the signal level drops significantly - I know this is not due to it's gain being much higher than clean signal because when I delete the block, and put in say a Teemah!, the clean (bypassed) signal level goes back to normal. I tried adding/deleting/switching out blocks a few times and each time, the signal drops below the level that it was supposed to be, when the A.fuzz block is bypassed. 

Another thing worth mentioning is, I did this in a preset that was pretty much filled up, so it might be that Helix was on the edge of it's processing power. I just tried the same thing in a new preset that only has an amp+cab block, stereo delay, noise gate and the A.Fuzz in it and everything works fine. Went back to the first preset, tried switching out a Teemah! block with the A.Fuzz, and the problem is there again.

[jbuhajla]

Hello!

I'd like to report an issue with the Arbitrator Fuzz block in the new 2.30.0 firmware. When I place it in a path everything is fine as long the fuzz is on, when I turn it off, the signal level drops significantly - I know this is not due to it's gain being much higher than clean signal because when I delete the block, and put in say a Teemah!, the clean (bypassed) signal level goes back to normal. I tried adding/deleting/switching out blocks a few times and each time, the signal drops below the level that it was supposed to be, when the A.fuzz block is bypassed. 

Another thing worth mentioning is, I did this in a preset that was pretty much filled up, so it might be that Helix was on the edge of it's processing power. I just tried the same thing in a new preset that only has an amp+cab block, stereo delay, noise gate and the A.Fuzz in it and everything works fine. Went back to the first preset, tried switching out a Teemah! block with the A.Fuzz, and the problem is there again.

If you have the fuzz as the first block in the chain and you have your input impedance set to AUTO, the input impedance changes when you activate the fuzz, but does not change back when bypassing it. The workaround is to control the input impedance with the same stomp (or snapshot) that you are turning on your fuzz with. Set it to make the impedance go to (around) 10k when the fuzz is on, and 1M when it is bypassed. 

[donrock1]

If you have the fuzz as the first block in the chain and you have your input impedance set to AUTO, the input impedance changes when you activate the fuzz, but does not change back when bypassing it. The workaround is to control the input impedance with the same stomp (or snapshot) that you are turning on your fuzz with. Set it to make the impedance go to (around) 10k when the fuzz is on, and 1M when it is bypassed. 

I tried it and it fixes the issue. Although I do think that is not something that should have to be set every time in order for a fuzz to work properly when placed first in the chain. 

Thanks for the explanation and workaround!

[jbuhajla]

I tried it and it fixes the issue. Although I do think that is not something that should have to be set every time in order for a fuzz to work properly when placed first in the chain. 

Thanks for the explanation and workaround!

Line 6 is aware of the issue. I am not sure if it will be a fix in the next firmware update coming up soon. 

[HonestOpinion]

If you have the fuzz as the first block in the chain and you have your input impedance set to AUTO, the input impedance changes when you activate the fuzz, but does not change back when bypassing it. The workaround is to control the input impedance with the same stomp (or snapshot) that you are turning on your fuzz with. Set it to make the impedance go to (around) 10k when the fuzz is on, and 1M when it is bypassed. 

 

Is this a bug or has the 'Auto' setting changed how it operates in a firmware update? I was under the impression that the 'Auto' impedance setting adjusted itself to whatever the first block in the signal chain was, regardless of whether that block is engaged or not. The reason given in the past for putting the fuzz first in the chain when using 'Auto' was because fuzz blocks generally sound better with a lower impedance and that the 'Auto' setting would adjust itself accordingly, but would maintain the same low impedance setting, regardless of whether the fuzz block was bypassed or not. I can easily anticipate a signal chain set to 'Auto' with the fuzz as the first block not sounding as good when the fuzz is not activated due to the low impedance setting (as set by 'Auto'). However, the the impedance setting should not be changing when it is activated unless you have assigned impedance to a stomp or snapshot and changed it explicitly.

 

I do agree that the workaround has always been to either assign the impedance parameter to the fuzz switch or to use snapshots to explicitly change the impedance from low to high when activating or bypassing the fuzz.

[jbuhajla]

Is this a bug or has the 'Auto' setting changed how it operates in a firmware update? I was under the impression that the 'Auto' impedance setting adjusted itself to whatever the first block in the signal chain was, regardless of whether that block is engaged or not. The reason given in the past for putting the fuzz first in the chain when using 'Auto' was because fuzz blocks generally sound better with a lower impedance and that the 'Auto' setting would adjust itself accordingly, but would maintain the same low impedance setting, regardless of whether the fuzz block was bypassed or not. I can easily anticipate a signal chain set to 'Auto' with the fuzz as the first block not sounding as good when the fuzz is not activated due to the low impedance setting (as set by 'Auto'). However, the the impedance setting should not be changing when it is activated unless you have assigned impedance to a stomp or snapshot and changed it explicitly.

 

I do agree that the workaround has always been to either assign the impedance parameter to the fuzz switch or to use snapshots to explicitly change the impedance from low to high when activating or bypassing the fuzz.

I don't think it is a bug. I believe it has worked this way all the time. I think it works as designed. However, I think a lot of users are finding it to be optimal to manually change input impedance with the fuzz in play.  

[HonestOpinion]

If you have the fuzz as the first block in the chain and you have your input impedance set to AUTO, the input impedance changes when you activate the fuzz, but does not change back when bypassing it. The workaround is to control the input impedance with the same stomp (or snapshot) that you are turning on your fuzz with. Set it to make the impedance go to (around) 10k when the fuzz is on, and 1M when it is bypassed. 

 

 

Is this a bug or has the 'Auto' setting changed how it operates in a firmware update? I was under the impression that the 'Auto' impedance setting adjusted itself to whatever the first block in the signal chain was, regardless of whether that block is engaged or not. The reason given in the past for putting the fuzz first in the chain when using 'Auto' was because fuzz blocks generally sound better with a lower impedance and that the 'Auto' setting would adjust itself accordingly, but would maintain the same low impedance setting, regardless of whether the fuzz block was bypassed or not. I can easily anticipate a signal chain set to 'Auto' with the fuzz as the first block not sounding as good when the fuzz is not activated due to the low impedance setting (as set by 'Auto'). However, the the impedance setting should not be changing when it is activated unless you have assigned impedance to a stomp or snapshot and changed it explicitly.

 

I do agree that the workaround has always been to either assign the impedance parameter to the fuzz switch or to use snapshots to explicitly change the impedance from low to high when activating or bypassing the fuzz.

 

 

I don't think it is a bug. I believe it has worked this way all the time. I think it works as designed. However, I think a lot of users are finding it to be optimal to manually change input impedance with the fuzz in play.  

 

Agree that the main point is that there may be presets where changing impedance manually (by footswitch) is optimal, particularly when you want to use a fuzz or a block that may sound better with a lower impedance somewhere in the signal chain other than the first block. Just pointing out that when set to 'Auto' the impedance is the same whether the first block is activated/bypassed or not. Activating the first block does not change the impedance. As a matter of fact, I have seen quite a few posts requesting that this be changed such that 'Auto' would adjust itself to whatever the first active block was rather than just the first block.

[almesy]

Editing a patch the display went black. It was still "lit" but the display was empty and hence, black. A reboot seemed ok have fixed the issue.

 

I did have the helix on for quite a long time. Maybe four or five hours. But it wasn't hot. Wasn't connected to the PC. And I'm on the latest firmware.

 

Same thing happened to me today.  My Helix is only 2 days old.  Didn't have mine on for as long as yours, maybe only about 20 minutes.  Screen went to a "glowing black".  Had to power off and turn back on to get back to normal.

 

Is this a "bug", or a screen defect I should be concerned with and maybe look to exchange my Helix at the store while within exchange policy?

[EricRenner]

Same thing happened to me today. My Helix is only 2 days old. Didn't have mine on for as long as yours, maybe only about 20 minutes. Screen went to a "glowing black". Had to power off and turn back on to get back to normal.

 

Is this a "bug", or a screen defect I should be concerned with and maybe look to exchange my Helix at the store while within exchange policy?

It hasn't happened to me since. But I'd like to know this as well.

[johnrjackson]

Picked up the new HX Effects pedal to use with my amps being more portable than the Helix floor unit. After creating a couple new presets, saving and rebooting 2 or 3 times, the unit fails to boot and is stuck at the screen that displays the firmware version. I've recreated the situation 3 times now and have opened a support ticket. While not detailed in the manual, I found that holding down the two lower right switches and rebooting does a factory reset which gets it "unbricked" again. Looks like a serious defect in the shipped 2.40 firmware or possibly I received a defective unit. It's not possible to update to 2.50 yet as the 1.12 updater does not have the necessary drivers for Windows nor is the 2.50 firmware available yet.

[MGblade]

ok guys lt user here

hope you can follow this

I asign almost all the amp block parameters to snapshot (use all 8) on my patches,a couple of times now after saving a patch after some tweaking some amp parameters (except on the snapshot which it was saved in) turn to 10.

it only happened on amp parameters not on effects yet. and it seems to be randomly had it with drive, bas, and channel volume parameters.

 

when I correct the settings and copy and paste patch to another slot the same thing happens. i use helix edit mainly.

 

last time it happened during rehearsal, channel volume was on 10 on all the other snapshots on the patch, (saved at 5.7) not funny.

[HonestOpinion]

ok guys lt user here

hope you can follow this

I asign almost all the amp block parameters to snapshot (use all 8) on my patches,a couple of times now after saving a patch after some tweaking some amp parameters (except on the snapshot which it was saved in) turn to 10.

it only happened on amp parameters not on effects yet. and it seems to be randomly had it with drive, bas, and channel volume parameters.

 

when I correct the settings and copy and paste patch to another slot the same thing happens. i use helix edit mainly.

 

last time it happened during rehearsal, channel volume was on 10 on all the other snapshots on the patch, (saved at 5.7) not funny.

 

Does this only happen when you copy and paste a snapshot? Are you saving before you cut & paste the snapshot? Not sure if you discovered a copy & paste bug. I will have to check   But until then wanted to throw out a couple of possibilities that don't necessarily have anything to do with copy & paste.

 

Did you have the channel volume parameter assigned to a snapshot (shows up enclosed by brackets)? If so, changing it to 5.7 will only change it for that snapshot. Also, you need to be careful to save after making a parameter change if you have your 'Global Settings'  --> 'Preferences' --> 'Snapshot Edit' = "Discard". This will cause your changes to be reset to whatever the preset/snapshot was last saved with unless you do a save before switching snapshots. With the "Discard" setting you will have to go into each snapshot and change the channel volume and save before proceeding to the next snapshot. 

[MGblade]

at first it only happened with copy and pasting presents.

last week it also happened with just saving a preset after tweaking it a bit.

 

yes I had the channel volume set to snapshots, and yes I have the globals set to "discard"

 

the thing is the patches worked fine until some point.

[MGblade]

thanks for the reply by the way.

[MGblade]

i also save first and then copy and paste.

[jerrymcp]

I'm not sure if this is the place to report HX Effects bugs. But I am having a problem with re-syncing the LFO. On the M Series and Helix a single press on the Tap Tempo will reset the LFO to that downbeat. I can't get the HXFX to respond to it at all. I am on firmware 2.5.0.

 

Thoughts? Is there some kind of setting I'm missing?

 

It would also be a great feature if midi Stop/Start commands for re-syncing the LFO. That way you could stomp it as often as you want and it doesn't change your tap tempo.

[Eagle117]

New HX Effects user.

 

Whenever I try to load HX Edit (newest version) I get the error code below. I've already updated the HX Effects to 2.50, reinstalled HX Edit, and tried different USB ports. Any suggestions on how to fix this? Being able to edit patches from the PC is a major reason I purchased.  

 

Badly formatted response from device error -8214

[jayfitt]

New HX Effects user.

 

Whenever I try to load HX Edit (newest version) I get the error code below. I've already updated the HX Effects to 2.50, reinstalled HX Edit, and tried different USB ports. Any suggestions on how to fix this? Being able to edit patches from the PC is a major reason I purchased.  

 

Badly formatted response from device error -8214

 

 

I'm getting the exact same error message with my brand new HX Effects!

[jbuhajla]

New HX Effects user.

 

Whenever I try to load HX Edit (newest version) I get the error code below. I've already updated the HX Effects to 2.50, reinstalled HX Edit, and tried different USB ports. Any suggestions on how to fix this? Being able to edit patches from the PC is a major reason I purchased.  

 

Badly formatted response from device error -8214

Open a support ticket with Line 6. 

[TacklingDummy]

HX EFFECTS is stuck in an endless boot screen showing firmware 2.40.0

[TacklingDummy]

HX EFFECTS is stuck in an endless boot screen showing firmware 2.40.0

 

SOLVED: I tried every trick I could to hard reset the HX. Finally, I managed by turning on the power while holding down different pedal and button combinations. It rebooted in it's original state and I was able to update the firmware to 2.50.0

 

Hold down the two middle foot switches on the bottom row while powering up.  This should reset the HX.

[HonestOpinion]

at first it only happened with copy and pasting presents.

last week it also happened with just saving a preset after tweaking it a bit.

 

yes I had the channel volume set to snapshots, and yes I have the globals set to "discard"

 

the thing is the patches worked fine until some point.

 

Just wanted to follow up with you on this. I have been unable to replicate your bug. So far I am seeing nothing out of the ordinary with snapshots but the expected copy & paste behavior on my device. I have the Helix and not the LT but they should behave the same way. I am wondering if this is only happening on specific presets or all of your presets? If so maybe you have some corrupt presets.

 

A couple of more things to consider might be firmware/Editor related. What version of firmware are you on? Does your Editor version match your firmware? I hate suggesting this because it sounds like the old cliche of reboot your computer whenever there is a problem but perhaps it might be worth backing everything up, and doing an explicit global reset or even updating the firmware again, and doing a global reset if this continues. Maybe someone else, particularly an LT user can provide a simpler solution. You can always contact L6 support and maybe they can think of something. Good luck with this.

[MGblade]

first of all thank you for you're help that's awesome.

I have at the latest firmware and editor.

2.5 is on it's way so I think I wait it out, if the problem remains after 2.5, I wil try to reboot.

[HonestOpinion]

first of all thank you for you're help that's awesome.

I have at the latest firmware and editor.

2.5 is on it's way so I think I wait it out, if the problem remains after 2.5, I wil try to reboot.

 

Good plan, all signs point to that not being too long a wait.

[chuskey]

I'm running into an issue with Variax and changing Variax models via snapshots.  

 

I have the Variax model assigned to snapshots, but the snapshots aren't changing the models properly.  I've double checked to make sure that the correct models are assigned in my patches and they are.  

 

So if snapshot 1 is an acoustic path with acoustic model and snapshot 2 is an electric path with an electric guitar, when I go from snapshot 1 to 2 and back to 1 it stays on the electric guitar model and doesn't switch back to the acoustic model as assigned in the snapshots. 

 

I have to reload the preset to get the acoustic to come back up.  But again after switching away from snapshot 1 and then back I'm stuck on electric guitar models again.

 

Or at times I've had it get stuck on the acoustic model and whenever I go to the electric path it stays on the acoustic model.  

 

I had this happen a few times before in the past and could work around it by unassigning the variax model to snapshots, saving the patch, then reassigning the variax model to snapshots.  Now that fix doesn't work.  I think this is the first time I've tried doing this since upgrading to 2.30.  So it could be that my work around no longer works on this firmware and/or it's more of an issue now?

 

I'm using a JTV69 with the latest firmware.  I shared my patch with someone today and they ran into the same issue. 

 

I have tried rebuilding a patch from a blank preset and it's still having this issue.  

 

Has anyone else run into this?  Is this a known issue?  

 

Here's the patch I tried that I'm experiencing the problem with:  https://www.dropbox.com/s/ppku3akh67003lh/Elec_Acoustic.hlx?dl=0