Helix Bug Reports

[TLF2007]

Firmware 2.01, USB 2 Port on WIndows 10 computer. Noticed that when connected via USB, the Helix software / driver would disconnect and require a DAW and Helix reboot. The software / computer would say that the hardware experienced a problem, etc.   

[robk916]

Firmware 2.01:  when using the Helix to change the amp channel I get a big volume spike.  It doesn't matter if it's going from clean to dirty or dirty to clean.  It doesn't happen when I'm switching channels but not changing to another patch.

[silverhead]

Firmware 2.01 and JTV-59 with latest firmware; editor not running:

 

Rapidly rotating the Variax Tone knob repeatedly for several seconds causes Helix to freeze. I was doing this to hopefully clean up a dirty Tone knob contact that was giving me some static when moving the knob normally. I am able to replicate this in my environment on several different presets - that's all I've tried so far. Can anyone else replicate this?

 

EDIT: After further testing it seems that this was resolved after a few minutes when I had rotated the knob sufficiently that there was no more static. Once a consistently clean signal was restored the freezing stopped. So probably not exactly a Helix bug although I will leave this post here in case it might help others to diagnose a similar freezing problem. Lesson: keep the pots/contacts clean.

[bryanchurchill]

MIDI Controller issue:

 

Helix Command Center allows users to set "Instant" CC messages upon changing of a patch.  GREAT for sending patch changes to external MIDI equipment or DAW plugins, or for other instant "on" MIDI tasks.

 

However, I've discovered that Helix also sends "instant" CC messages for any footswitch saved with MIDI commands that are set to "Toggle CC." 

 

Why is this a problem?  Well, any footswitch saved in a Helix patch sends an "instant" toggle message, thus instantly toggling the MIDI message target without waiting for me to STOMP the footswitch.  This has got to be a glitch.

 

For example, let's say I have a patch with a footswitch saved with a command set to toggle a plugin housed in my DAW.  If the plugin is saved in my DAW in the "off" position, Helix turns the plugin "on" "instantly" upon landing on the patch (rather than waiting until I STOMP the switch "on" when I'm ready to use it.

 

FYI.  I've confirmed that Helix is sending these "instant" toggle messages by using a program "Midi Monitor" that reads all MIDI messages coming out of the Helix.  When I change to a patch with a footswitch saved with a "Toggle CC," there is an instant CC sent.

 

FYI #2...  Footswitch commands set to send regular CC messages are not sent "instantly."  Helix waits until I stomp to send the regular CC message.  But the regular CC message (non-toggle) setting is not useful for on-off messages.  They are momentary only, and therefore not appropriate for stomp box or any MIDI targets that are "on" or "off" (hence the reason for toggle CC's in the first place!).

 

I developed a workaround using the Bome MIDI Translator program, setting all of my toggle messages as "Note On" and "Note Off" and having Bome translate them to CC toggle "On" and "Off" messages.  A hassle, but it worked.

 

Please fix this.  I'm sure it was unintended.  Honestly, it makes "Toggle CC's" useless.

[TexLefty65]

MIDI Controller issue:

 

Helix Command Center allows users to set "Instant" CC messages upon changing of a patch.  GREAT for sending patch changes to external MIDI equipment or DAW plugins, or for other instant "on" MIDI tasks.

 

However, I've discovered that Helix also sends "instant" CC messages for any footswitch saved with MIDI commands that are set to "Toggle CC." 

 

Why is this a problem?  Well, any footswitch saved in a Helix patch sends an "instant" toggle message, thus instantly toggling the MIDI message target without waiting for me to STOMP the footswitch.  This has got to be a glitch.

 

For example, let's say I have a patch with a footswitch saved with a command set to toggle a plugin housed in my DAW.  If the plugin is saved in my DAW in the "off" position, Helix turns the plugin "on" "instantly" upon landing on the patch (rather than waiting until I STOMP the switch "on" when I'm ready to use it.

 

FYI.  I've confirmed that Helix is sending these "instant" toggle messages by using a program "Midi Monitor" that reads all MIDI messages coming out of the Helix.  When I change to a patch with a footswitch saved with a "Toggle CC," there is an instant CC sent.

 

FYI #2...  Footswitch commands set to send regular CC messages are not sent "instantly."  Helix waits until I stomp to send the regular CC message.  But the regular CC message (non-toggle) setting is not useful for on-off messages.  They are momentary only, and therefore not appropriate for stomp box or any MIDI targets that are "on" or "off" (hence the reason for toggle CC's in the first place!).

 

I developed a workaround using the Bome MIDI Translator program, setting all of my toggle messages as "Note On" and "Note Off" and having Bome translate them to CC toggle "On" and "Off" messages.  A hassle, but it worked.

 

Please fix this.  I'm sure it was unintended.  Honestly, it makes "Toggle CC's" useless.

 

Bryan - I think that if you change the "MIDI PC Send/Receive" option to "Off" (found in Global Settings - MIDI Tempo) this may solve the problem. With this off I believe no MIDI messages are sent out from Helix when changing presets.

[phil_m]

MIDI Controller issue:

 

Helix Command Center allows users to set "Instant" CC messages upon changing of a patch.  GREAT for sending patch changes to external MIDI equipment or DAW plugins, or for other instant "on" MIDI tasks.

 

However, I've discovered that Helix also sends "instant" CC messages for any footswitch saved with MIDI commands that are set to "Toggle CC." 

 

Why is this a problem?  Well, any footswitch saved in a Helix patch sends an "instant" toggle message, thus instantly toggling the MIDI message target without waiting for me to STOMP the footswitch.  This has got to be a glitch.

 

For example, let's say I have a patch with a footswitch saved with a command set to toggle a plugin housed in my DAW.  If the plugin is saved in my DAW in the "off" position, Helix turns the plugin "on" "instantly" upon landing on the patch (rather than waiting until I STOMP the switch "on" when I'm ready to use it.

 

FYI.  I've confirmed that Helix is sending these "instant" toggle messages by using a program "Midi Monitor" that reads all MIDI messages coming out of the Helix.  When I change to a patch with a footswitch saved with a "Toggle CC," there is an instant CC sent.

 

FYI #2...  Footswitch commands set to send regular CC messages are not sent "instantly."  Helix waits until I stomp to send the regular CC message.  But the regular CC message (non-toggle) setting is not useful for on-off messages.  They are momentary only, and therefore not appropriate for stomp box or any MIDI targets that are "on" or "off" (hence the reason for toggle CC's in the first place!).

 

I developed a workaround using the Bome MIDI Translator program, setting all of my toggle messages as "Note On" and "Note Off" and having Bome translate them to CC toggle "On" and "Off" messages.  A hassle, but it worked.

 

Please fix this.  I'm sure it was unintended.  Honestly, it makes "Toggle CC's" useless.

 

I actually don't think the thing with the CC Toggle is a bug. I think it's related to how CC Toggle commands are treated with Snapshots. Per page 36 of the manual:

 

Snapshots also store and recall the following MIDI, CV, and Ext Amp messages sent to external devices from the Command Center:

• The value of any Instant MIDI CC, Bank/Prog, MMC, and CV Out messages
• The state (dim value or lit value) of any CC Toggle or CV Toggle messages assigned to footswitches
• The state (dim or lit ) of any Ext Amp messages assigned to footswitches

So I think that when you load a preset, the active snapshot is being loaded, and the value of the CC Toggle is being sent out. If you want the pedal to be off, you should just make sure you have the CC Toggle value set appropriately in the snapshot that's active when you load your preset.

 

There is actually a bug associated with the MIDI CC Values assigned to footswitches, though, that I discovered (already been reported and logged by Line 6). That bug is somewhat similar to what you're talking about here in that if you have a MIDI CC value assigned to a footswitch, the Command Center lets you assign a different value in each shapshot, and sends that value out upon loading each snapshot. So it can cause some unexpected behavior. If you have assigned the CC Value to the footswitch prior to setting up your snapshots, it's not an issue because all snapshots will have the same value for that CC.

[d0stenning]

i've been using the HELIX Mac 1.0 USB driver for a while now with no problems.  

 

Except today - when I was trying out my new Fremen HELIX patches. 

 

I was playing backing tracks via iTunes from my 2011 iMac ( El Capitan latest ) into the HELIX via USB.  

 

All was fine until I selected the Fremen - preset  Pull Me Under - which must be using a lot of DSP power. 

 

When using the preset by itself - no issues. but as soon as i tried playing a track o iTunes along with it - got lots of noise and crackles. 

 

Switching to a different patch ( a Fremen one ) made all the crackles go away.  

[lbro]

2.01 Firmware

Win 7

High end desktop DAW

Other equipment: RME 802 FireFace Interface set to slave.

 

ISSUE: AES/EBU Helix port channels. New cable installed, Helix set to master and connected to the RME 802. On average of about one incident per every 2 hours of continuous signal running over the AES channels I get an audio dropout. Then the sync lights go out on the RME. The RME then looks for the master clock, renegotiates the session and I get a solid sync again.

 

Pulling the Helix out of the loop and setting the RME 802 back to being master clock with other Adat equipment installed is rock solid and has been for about 2 years. Not one dropout in that time.

 

I will try a replacement cable but at this point it may be my Helix is not doing well as a master clock source via the AES port on the Helix. I will update once I test with the new cable.

 

Thanks,

LB

[lbro]

2.01 Firmware

Win 7

ASIO Buffer issue

High end desktop DAW

 

ISSUE DETAILS: I bought the Helix being excited to use the USB reamping feature. I set it up and gave it a try. I found the lowest ASIO buffer setting produced pops and crackles. Adjustment made to the right selecting the very next buffer setting produce unusable latency results. Simply put one could not monitor the guitar track and play to tracked drums due to the excessive latency as it throws off your timing.

 

SUGGESTION: Add more buffer position settings. At the very least add one that is between the 2 far left setting adjustment increments.

Additionally it would be nice to know what the buffer settings actually are. I suggest adding values to each buffer setting location so the user knows the buffer value.

 

Thanks,

LB

[phil_m]

2.01 Firmware

Win 7

ASIO Buffer issue

High end desktop DAW

 

ISSUE DETAILS: I bought the Helix being excited to use the USB reamping feature. I set it up and gave it a try. I found the lowest ASIO buffer setting produced pops and crackles. Adjustment made to the right selecting the very next buffer setting produce unusable latency results. Simply put one could not monitor the guitar track and play to tracked drums due to the excessive latency as it throws off your timing.

 

SUGGESTION: Add more buffer position settings. At the very least add one that is between the 2 far left setting adjustment increments.

Additionally it would be nice to know what the buffer settings actually are. I suggest adding values to each buffer setting location so the user knows the buffer value.

 

Thanks,

LB

 

I'm a little confused as to what you're trying to do here. If you're monitoring through the Helix, there should be no latency at all. If you're re-amping, yes, I suppose there will be some latency because you're playing the recorded dry guitar track from your DAW. But under normal conditions, where you're playing from your DAW and recording with the Helix, there should be none as long as you're monitoring directly from the Helix.

[lbro]

I'm a little confused as to what you're trying to do here. If you're monitoring through the Helix, there should be no latency at all. If you're re-amping, yes, I suppose there will be some latency because you're playing the recorded dry guitar track from your DAW. But under normal conditions, where you're playing from your DAW and recording with the Helix, there should be none as long as you're monitoring directly from the Helix.

 

Yes I realize I could monitor direct from the Helix output latency free, but I was attempting to monitor the "wet" track at or on the DAW to ensure my recorded guitar tone being laid down sounded as I expected it should. How can one for instance be sure there are no pops and crackles as tracks are recorded unless they monitor the actual tracks? I can easily do this with the RME device by "manually" setting up for a reamp situation and not using the USB built in reamping feature. In fact I am now doing that. I can use a buffer setting of 256k there and it works well with no perceptible latency delay to my ear. It seems the reason it works better as an ASIO driven interface than the Helix ASIO driver/interface. I think is due to the fact there are more buffer setting choices and you can dial in the best setting to reduce both latency and the dreaded pops & crackles. Would it be that hard to make a programing change to the ASIO Helix driver to allow more choices for the buffer settings? I am not a programer so I don't know the answer to that question. But I feel it should be looked at. At present the Healix ASIO driver simply makes too big of a jump between the 2 lowest buffer settings. This issue has been reported to technical support with a request it be taken under consideration. My hope in posting here was that others who might have experienced this would chime in and add weight to this point.

 

I could set up the USB reamp method again using the Helix ASIO driver to try and determine the actual latency lag in ms but not sure that is helpful information. Also, if the wet track(s) being recorded (both the initial one and the later reamped ones) are latent by too big of an amount then the user should be moving the recorded guitar tracks to line up with the drums for instance. Otherwise the recorded tracks are going to offset and latent in relation to other recorded tracks. One could attempt to make a compensation adjustment in the DAW for the Helix wet tracks to overcome this. But if the suggested changes were made to the ASIO driver it may or should not be necessary. In parting I will say I measured the latency for the reamped wet track vs the original dry guitar track using the RME interface ASIO driver and it is in the range of 1.5-2ms. The helix interface will be much greater than this in the latency round trip. I would guess it to be a fair amount over 10ms on setting 2 from the left in the Helix ASIO driver settings.

 

Hope that clears things up. If not let me know and I will attempt to clarify.

LB

[Ka5par]

Changing the 1-st cab in dual cab block resets the second cab to default.

 

Firmware 1.06.05.

 

A very frustrating bug that survived the last update. Hopefully in the next one...

[pilottes]

That's why a firmware release every 3, 4 , 6 months is not adequate.

[phil_m]

That's why a firmware release every 3, 4 , 6 months is not adequate.

 

It just depends on the severity of the bug, I'm sure. There's been a couple times when they've released a patch update the next day because of certain bugs. But I don't know that it's realistic to treat every single bug with such urgency. Seems there are some bugs that simply annoyances more than showstoppers.

[BrownNote71]

Piling on to the volume pedal block randomly dropping to 1 or 2%. This really is a gig show-stopper. Happens just like this video: https://www.youtube.com/watch?v=7PqJemwEC3U. 

[madteto]

Problem with Drop volume to 1% here, and any response yet, 2.01 version!, A Big problem to play live!

[jpdennis]

Problem with Drop volume to 1% here, and any response yet, 2.01 version!, A Big problem to play live!

 

You'll need to contact support and open a ticket if you haven't already.

 

Dennis

[madteto]

You'll need to contact support and open a ticket if you haven't already.

 

Dennis

 

Thanks I open my ticket today!

[yoMuzicMan]

Using Helix Rack 2.01 and foot controller with Helix Editor.  I configure my patches with snapshots all the time.  And I edit them exclusively with the Helix editor software in Windows 10.  

 

Over time, the Helix editor no longer updates the snapshot number and name in the top left corner when I change the snapshot from the foot controller.

 

The snapshots seems to be in sync between the foot controller and the editor as I see block settings change when I select different snapshots from the foot controller.  If I press on the foot controller snapshot button several times in a row, sometimes the snapshot number and name in the editor will finally update.  But after a while, this doesn't work either.

 

Turning off/on the Helix rack solves this problem for a while until it happens again.

[markus506]

Helix update 2.10 (floor model):

 

I use 8 snapshot mode. I changed the colors of the snapshots using the new option. Instead of the default option of the 'dim/bright', I changed this to 'off/bright'. The LED rings for the inactive switches on the bottom row turned off. However, the inactive LED rings for the top row remained on. I tried switching patches, saving in different states, and they remained this way. This may possibly be a bug.

[Rocco_Crocco]

2.10 Floor

 

Upon reboot, EXP1/EXP2 is visible above the expression pedal. After changing to another snapshot, only EXP1 remains. EXP 2 no longer is visible, nor can I access it by pressing the toe switch on the exp pedal.

[hefonthefjords]

2.10 Floor

 

Upon reboot, EXP1/EXP2 is visible above the expression pedal. After changing to another snapshot, only EXP1 remains. EXP 2 no longer is visible, nor can I access it by pressing the toe switch on the exp pedal.

 

Solution for this problem provided here...

 

http://line6.com/support/topic/24048-fw-210-expression-pedal-question/?p=183609

[bsd512]

Firmware 2.10 Editor Bug - Snapshot Rename

 

When renaming a snapshot by clicking the camera icon and selecting rename - the first time that is done it works normally.

If one then attempts to rename another snapshot, the editor accepts the input, but does not rename the snapshot, it goes back to the original name.

 

Exiting and restarting the editor did not fix - it behaves the same as above - first attempt works, all subsequent ones do not.

 

Renaming on the Helix device itself works fine - so it appears to be an Editor bug.

[Joepeggio]

Solution for this problem provided here...

 

http://line6.com/support/topic/24048-fw-210-expression-pedal-question/?p=183609

Solution did not work for me.  Did all saving to a T.  When rebooting unit, it reverts back to problem.  Plus i am not going through 20 presets with 4 snaps to fix this.  

[HonestOpinion]

Solution did not work for me.  Did all saving to a T.  When rebooting unit, it reverts back to problem.  Plus i am not going through 20 presets with 4 snaps to fix this.  

 

The solution does work for me but it is a mighty large inconvenience to have to do the workaround to every preset. Although there is a workaround (perhaps not working for everyone or every preset) I think this is a crippling enough bug to warrant a quick patch and a fixed version of the firmware as quickly as possible. I hope we will not have to wait months for this one. This is a terrific firmware update, just needs a bit of massaging. Please don't kill the messengers.

[HonestOpinion]

2.10 Floor

 

Upon reboot, EXP1/EXP2 is visible above the expression pedal. After changing to another snapshot, only EXP1 remains. EXP 2 no longer is visible, nor can I access it by pressing the toe switch on the exp pedal.

 

 

Solution for this problem provided here...

 

http://line6.com/support/topic/24048-fw-210-expression-pedal-question/?p=183609

 

 

The solution does work for me but it is a mighty large inconvenience to have to do the workaround to every preset. Although there is a workaround (perhaps not working for everyone or every preset) I think this is a crippling enough bug to warrant a quick patch and a fixed version of the firmware as quickly as possible. I hope we will not have to wait months for this one. This is a terrific firmware update, just needs a bit of massaging. Please don't kill the messengers.

 

Sorry for the repetition in this topic as I posted this elsewhere but I feel my earlier comment requires modification given the fact that this 'bug' does not occur with newly created presets. So... I have to amend my earlier comment or risk being a hypocrite. I have stated on the forum before that if new functionality or better sound occasionally require that we dig in and modify old presets I am more than willing. Well, here is a perfect example. We now have major improved functionality on the expression pedal behavior. Would it have been nice if the upgrade had been seamless with old presets? Sure! However, I am perfectly willing to go in and modify my old presets if they released this firmware, perhaps aware of this 'bug'/limitation, but also knowing the benefits the new firmware brought or not wanting to make us wait too long for it.  Of course, if there is a quick fix that will obviate the need for the workaround, please bring it as this one requires a lot of work as it affects every snapshot! Thanks again for the new features Line6, I am more than willing to spend a little time adjusting old presets to get this in return!   :)

[talwilkins]

Firmware 2.10 Editor Bug - Snapshot Rename

 

When renaming a snapshot by clicking the camera icon and selecting rename - the first time that is done it works normally.

If one then attempts to rename another snapshot, the editor accepts the input, but does not rename the snapshot, it goes back to the original name.

 

Exiting and restarting the editor did not fix - it behaves the same as above - first attempt works, all subsequent ones do not.

 

Renaming on the Helix device itself works fine - so it appears to be an Editor bug.

Yes, this is irritating. I found I could rename by just using the space bar. After that I can rename to whatever I want. That's my workaround.

[bsd512]

Yes, this is irritating. I found I could rename by just using the space bar. After that I can rename to whatever I want. That's my workaround.

 

Thanks!  I'll give that a try.

[AdInfinitum]

There is defintely something amiss with backing up User patches. I backed up my User1 setlist and individual patches, loaded new firmware, did reset.

 

Factory patches updated, but whn i tried to import setlist, it did upload them, but borked Factory 2 Presets. Only half loaded and they seemed to be the old set.

 

Tried saving that user setlist and rest, same thing.

 

Any solutions. Luckily i only had about 8 original patches, so not a huge loss.

[phil_m]

There is defintely something amiss with backing up User patches. I backed up my User1 setlist and individual patches, loaded new firmware, did reset.

 

Factory patches updated, but whn i tried to import setlist, it did upload them, but borked Factory 2 Presets. Only half loaded and they seemed to be the old set.

 

Tried saving that user setlist and rest, same thing.

 

Any solutions. Luckily i only had about 8 original patches, so not a huge loss.

Did you install the latest version of the editor?

[AdInfinitum]

Yes. Also rebooted after several tries of reinstalling my patches.

[tagmusenmagnus1]

You probably wound't consider this a bug it is some i really think you need to change: 

in the Harmony delay the settings for "Voice Shift" doesn't make any sense in a musical way. 
Since no shift is labeled "0" you end up with "1" meaning the interval of a 2nd and "2" meaning a 3rd and so-on. 4 is a 5th. 

Well, of course i can learn that this is the case, but it would be better to give the values: Unison, 2nd, 3rd, 4th. 

[HonestOpinion]

You probably wound't consider this a bug it is some i really think you need to change: 

 

in the Harmony delay the settings for "Voice Shift" doesn't make any sense in a musical way. 

Since no shift is labeled "0" you end up with "1" meaning the interval of a 2nd and "2" meaning a 3rd and so-on. 4 is a 5th. 

 

Well, of course i can learn that this is the case, but it would be better to give the values: Unison, 2nd, 3rd, 4th. 

 

That is actually a pretty typical numbering system for harmonizers. The '5' on a harmonizer would generally never be a 5th as the harmonizers numbers represent half steps. A 5th is 7 half steps above the root in a major/minor scale, so a 5th is represented by the number '7' (half steps) in a harmonizer . A whole step between each note in the scale with the exception of E-F, and B-C. Each half step in a harmonizer is represented by its own number so you can use the harmonizer with various scales including sharp and flat keys. I hear you though, it does cause you to have to do a little calculation.

[tagmusenmagnus1]

That is actually a pretty typical numbering system for harmonizers. The '5' on a harmonizer would generally never be a 5th as the harmonizers numbers represent half steps. A 5th is 7 half steps above the root in a major/minor scale, so a 5th is represented by the number '7' (half steps) in a harmonizer . A whole step between each note in the scale with the exception of E-F, and B-C. Each half step in a harmonizer is represented by its own number so you can use the harmonizer with various scales including sharp and flat keys. I hear you though, it does cause you to have to do a little calculation.

Yes. But when using halfsteps it is the only solution if you only want to use numbers. 

This is an actual harmonizer using the intervals of the scale. 

 

I havn't checked but i am pretty sure that the smart harmony does not use the system you are referring to.

[MonkeyXT]

Have other Helix Rack & Control users chimed in on this? I might have missed that.

I'm on current FW 2.10.

I've thought all this time the rack unit with physical EXP 1 and 2 plugged in wasn't being affected by the volume block drop to 1% issue, but I guess that's because I always shunt volume type duties to EXP2 (even with previous L6 units, I'd always add a second EXP to the shortboard for instance).

Now, having done a bit of testing with EXP 1 - previously set to use the toe-switch (Mission Helix EXP w/toe-switch) for on-off, generally for wah in my case - now set to auto engage by position, I have now found a couple of times being hit with the wah coming on by itself with zero physical movement of the pedal itself. Checking the parameter, I saw it was at 1% while still at 'parked' toe-down position (I set the auto-engage to come off of parked there, as opposed to heel-down).

 

I'll have to skip using this feature until it's sorted.

[glorioso]

Huge lag with the editor when switching patches on macbook pro

[phil_m]

Huge lag with the editor when switching patches on macbook pro

 

That's probably to be expected. How long of a lag are you talking about, though?

[krisvibe]

Firmware 2.10
Variax Standard and/or JTV-59

 

Issue: Variax tone knob does not lock when assigned

 

Details: Currently have Variax settings by preset; Preset Variax Lock Control set to Tone Knob, with Preset Variax Tone Knob set to 10.  For any preset where I have the Variax Tone Knob set to control a parameter (in this case Drive on the amp), it will operate as expected UNTIL i move the pickup selector switch.

 

Example:
Preset: Spank-5, Amp Drive = 2.0
Move tone control - no audible change to Variax tone, Amp Drive changes (between 2.0 and 5.0)

Using pickup switch, change Variax to Spank-4

Tone knob now also affects guitar tone as well as Amp Drive

 

Only way to correct is to reset the preset (click on the preset button)

[phil_m]

Firmware 2.10

Variax Standard and/or JTV-59

 

Issue: Variax tone knob does not lock when assigned

 

Details: Currently have Variax settings by preset; Preset Variax Lock Control set to Tone Knob, with Preset Variax Tone Knob set to 10.  For any preset where I have the Variax Tone Knob set to control a parameter (in this case Drive on the amp), it will operate as expected UNTIL i move the pickup selector switch.

 

Example:

Preset: Spank-5, Amp Drive = 2.0

Move tone control - no audible change to Variax tone, Amp Drive changes (between 2.0 and 5.0)

Using pickup switch, change Variax to Spank-4

Tone knob now also affects guitar tone as well as Amp Drive

 

Only way to correct is to reset the preset (click on the preset button)

 

You have the Lock Variax Controls setting under Knob 5 in the input block set to "locked"?

[kjonsson]

Changing the 1-st cab in dual cab block resets the second cab to default.

Firmware 2.10.

 

If you don't fix this really soon, your car radios will start to only play polka death metal every Thursday - all day!