PierM

It will never happen.

Hi, Widi Master and Widi Jack are fully compatible with any HX device. Widi Master will take power directly from the Midi Out port. UHost doesnt work due a code wall in the firmware. CME asked L6 to fix the issue, but it will never happen.

There is no (yet) BT headphone available in any similar device in the market as the latency would make the experience miserable. :)

Isnt about signal loss...but about doubling the risk of signal drops and glitches due a busy wifi channel.

Because the fx loop stacks another "layer" of noise as is, so any overdrive pedal it's pulling this noise up into the signal. Experience may vary, but I believe it's a well known issue with these loops. This is the exact topic of this thread :D

Imho you should not put any Fuzz/OD in the FX Loop, nor any other pedal that is supposed to drive and boost a signal. That's a rule I personally follow since day one, and I do really believe it's related to I/O circuits at the ports, so nothing you can change software side. Even the most clean clone of Klone pedal I put the in the Loop sounds noisy, and also it does work differently then when it's running in front (as it should, imho). Personally, the only real downside of the loops, is they do suck a bit of tone, which is most evident with clean sounds, but it's always a compromise I guess. :) EDIT; added "IMHO" to prevent sensible people to feel offended.

Im running an entire pedalboard filled with pedals in the FX loop (of course no gain, those are either coming from HX or BEFORE the HX main input) and always worked great. Of course the more AD/DA you stack, the closer the noise floor....but nothing to call home about.

If you need just few effects per channel you could try this

With the HX Stomp isnt possible because you can only have a single stereo path, as you only have a single DSP. As Silverhead said, you could with the big brothers, LT and Floor/Rack. (you could split the input and re-merge at the output, but DSP isnt powerful enough, so all you can do is a bunch of FX)

The point here is that a USB audio interface is 99% using the USB 2.0 protocol (even if you'd set these consumer interfaces to their max rates, the final required bandwidth would be a fraction of a fraction of the 2.0 available speed) while USB 3.0 and 3.x are needed for high speed data transfer, like USB disks and anything else does benefit from an high speed bus. That said, a USB device that is only using the 2.0 protocol, should work with any "blue port" connected to a 3.x bus. It will end just using the bandwidth it does need, that's it. Isn't a different technology, just a faster bus. So, while it is true (and obvious, tech wise) that Helix (and any derivate) are USB 2.0, they shouldn't have any issue with a 3.x. As I said, I'm also using only 3.x ports, for both PC and Mac environment, and everything is fine. IME, these problems are random and hard do isolate/debug, and are more caused by what's being shared at USB Root level by the chipset, or cable lenght, or even power management. Could be the updater Im pretty sure that when you get that issue on a blue port, and then it works on a black port, isn't about 3.0 VS 2.0, but about what was being shared by that 3.0 port at Root level (single ports from the Root are pretty rare, especially in laptops, so they are often being shared with other ports, which means multiple calls at the same root level affecting polling, through an hub).

The HD500X is a legacy product since 2021, which means no longer receives updates for modern OS.

uHost is a BLE Midi Host that you can plug to any MIDI device or controller that has has a compliant USB port. This will give the device access to MIDI BLE. So isnt the uHost that has to talk with the Pod (which would be impossible since the Pod doesnt have BLE), but it's the uHost which gives BLE MIDI to it. I use it with my HX Stomp, awesome stuff.

Just to remind you guys we are in 2024. Modern PCs and Macs, doesn't even use a USB 2 hardware root, so this isn't really the point. USB 3 ports they do auto run with 2.0 speeds when required by the device plugged. Point is these updaters are extremely sensible to many things, as basically everything coming from L6. :) Isn't always user error, sometimes it's just bad HAL from the companies.

There is nothing strange when it comes to Native licensing system, which is an utterly garbage by default... it's so unstable and sensible to any minimal system change that sometimes does throw that error from nowhere and you need to start doing random crap to your system until you get it working again. We are trying to find patterns and streamlining solutions over here, but every new version seems introducing more error variables and error randomness.

Those pickups are VERY hot, so they need some good clearance under strings.