PierM

These reports of faulty knobs after update can be related to the ballistic code they added/changed in this firmware. I do also have a glitchy knob after 3.5, which was working flawless before. Cant be just another coincidence...:)

We do know and we do mostly agree; the download page is sloppy and unnecessarily convoluted, and the front page OS indication is stuck on old gen operative systems. Yes, the firmware update procedure it can be a pain in the arse and can still randomly go wrong for some unclear reason, even for veteran users (like me, and happened more than once). But it is what it is, and L6 doesn't give a damn of what we say over here....so take a big breath, and follow the above indications. Good luck! :)

Many updates ago I also had that corrupted LCD after an Helix update, but I quickly and easily solved following those same advices. If you tried all the suggestions above, there is nothing more you can do. Contact support through a ticket.

Ask ChatGPT. Joking, but seriously, no way we can give you any advice with that post. Shrug...:)

That's the only difference I can think of between the two lines. You could also experience a very similar situation when comparing Helix to Native through the average audio interface. That impedance circuit at the input isn't a small aspect when it comes to headroom and available dynamics (which are more or less the same thing).

The difference in tone you were hearing was probably all related to the missing impedance circuit at the input of the HX FX, which is instead present in all the Helix/HX modeler family.

Everything you describe sounds normal and expected. Active devices, with an impedance load and a buffered circuit. Impossible to have them acting just like a cable when passing through them.

Before messing up with the hardware I'd also try different cables to see if there is a jack that works better with it. I'm saying that because I do have a cable that it's way easier to plug and unplug than the others, due (I guess) the slightly different shape of the tip/ring.

I do have a 2011 JTV59, and jack is still tight as hell... but actually I like it, feels like a solid connection.

Yep, but shorting a condenser (this is risky even when unit is turned off) or a diode, or a Sharc...would be probably worse. :)

Just open the unit and remove the thing. It could be a bolt, or a bit from the XLR lock systems...or any other metal bit that could easily short something on the PCB and damage the unit. Easy to solve. ;)

This is when you realize ChatGPT is useless to solve real life problems.

Hx and Helix arent sharing the same I/O hardware, so input/output blocks that are set in a preset for Rack, cant (and wont) translate properly.

As soon as you create your presets on the Rack, "emulating" the smaller HX unit, everything will be ported correctly. For example, if you need to make them 1:1 with HX Stomp, you need to respect path and block limitation (due the different DSP layout and different input/output block code), use only the first 3 FS on the controller (FS 1, FS2 and FS3), or also FS4 and FS5 if you have an external controller for the Stomp, etc etc... Another option is to use Helix Native in HX Stomp compatibility mode, which means you are almost 100% sure they will also mirror on the Rack (still input/output block code is different, so it may require some further editing - also FX loops aren't available). After that you could refine the preset assigning scribble strips and snapshots on HX Edit. The 3+2 footswitch on the Stomp preset will be ported to Helix Controller FS1 to FS5. In the case of LT they are pretty much same "core", and no scribble strips, so that would be a much easier porting.

Yep. I get the same 404 error from Italy, but can correctly see the product page if using a US Proxy.

There is no such thing as USB Send/Return block and I believe for a good reason, since this would add an awful extra round trip of latency and a potential mess since there wouldn't be clock lock between internal sampling and external. What you can do is to receive audio from USB (USB input block), or send audio to USB (USB output block). Or, you can have USB passing through the Helix signal through USB 1/2.

The transmitter does auto standby after 4 minutes without signal. So, as soon as you stop playing, the transmitter will auto shut down after 4 minutes with no audio, to preserve the battery charge.

Probably all the drivers are being deprecated by core isolation memory integrity. Only way to allow windows 11 to load those drivers is to turn memory integrity off.

https://line6.com/support/topic/55438-changing-action-of-shuriken-variax/

Input distortion doesnt mean anything without specifying at which stage, since every single stage of an audio chain has an input and an output. Im pretty sure your engineer didnt meant the cause of distortion was happening at your helix input. Something got lost in translation.. :)

Any daw will do the job. Just select Helix as audio interface input and your mac speakers as audio interface output. The processed signal from Path A will be available at USB 1/2. (better to use Core Audio drivers at 48Khz, less latency for live monitoring)

Studio monitors and guitar amps are like apple and oranges. Two very different device for two very different purposes... :) I find my Yamaha HS5 (mounted into a small studio where a HS8 would sound boomy at volume parity) very helpful for creating tones at studio volumes. Since a modeler is simulating a mic'ed amp that's a pretty much correct use, if you don't need stage volumes. For rehearsal or small gigs a 12" FRFR would be a better choice. In any case I would use a guitar amp as would sound terrible with a modeler, and if I were you I wouldn't expect or ask to any monitor or FRFR to sound like your guitar plugged to your guitar amp. I still see too many guys expecting a modeler plugged into a 8" monitor to sound like a stack of marshals. :)

I believe you are confusing Tap/Tempo with Sync/Clock. They are two very different things. Tap Tempo does trigger internal clock. External clock link directly to internal clock, through PPQs, bypassing Tap Tempo. What you are doing sending a continuous sequence of CC64 is to just triggering the tap tempo, which is an input always passing through its own little code logic to calculate and interpolate a time delta between consecutive Taps. This is not a clock, it's just a way to remote the Tap Tempo using external controllers. A typical clock isn't working with just a message per quarter, it needs to send a least 24 PPQ, with the slave calculating its own tempo based on that input which can't be the Tap listener. :) If you want to sync your Helix with an external master, you need to feed it with a MIDI clock. As soon as you send a MIDI clock, and you set your Helix to receive MIDI Clock, you will see that tempo led will start flashing Blue, and Helix will try to stay clocked with that master. Tap Tempo will be bypassed by the external Clock. To achieve a solid sync it's always better to not have other busy MIDI traffic going on, which would introduce jitter and latency making tempo unstable. "Helix can send and receive MIDI clock via its MIDI 5-pin in/out, as well as via USB. MIDI Clock options can be enabled and configured within the “Global Settings > MIDI/ Tempo” options. MIDI Clock Send: Transmit MIDI clock to synchronize the tempo of external pedals, rack gear, and software to the current Helix TAP Tempo rate. MIDI Clock Receive: Synchronize the Helix time-based effects (such as delay and modulation) to incoming MIDI clock from external DAW software, drum machines, keyboard workstations, or other modelers. Note that the Helix Control’s TAP footswitch will flash blue (instead of the default red) to indicate the incoming tempo rate when receiving MIDI clock."

Im pretty sure you are not getting any Input Distortion. Problem is somewhere else. ;)

Impossible to track down a problem like that from our screen, since there are too many variables. Said that, I couldn't hear any noise on the two clips using studio monitors, apart the background hum which is present on both.