SaschaFranck

As far as (1) goes, set the volume block to "logarithmic" rather than "linear" (which is the default).

Usually, you use them instead of a cab.

Connect two plain guitar cables to the left and right input, done (ok, you will also have to connect the passive speaker to the active one, the cable should be delivered along with the speakers).

Fwiw, I'm using a mixture of 4 snapshots and 6 switches (4 switches before 2.9), the switches being assigned to the same (or pretty similar) things all the time, but that only helps a little. The snapshots are sort of readable (due to the inverted camera lense), but using the switches can easily become guesswork. Seriously, inverting the entire shebang would help a whole lot (as there can't be anything done to the LEDs themselves). I will now try to find out which LED color works best under critical lightning conditions and change all LEDs to that color (sure, I will lose color as a job indicator, but I couldn't care less).

I think they should be fine but you shouldn't expect to do much techno jamming with them.

Obviously. But then, trying out ASIO4All is a pretty valid troubleshooting option. Apart from that, for various other reasons Macs aren't a turnkey solution at all anymore (at least not in case you're also using plenty of 3rd party software). Not exactly because of technical issues, though...

Well, I'm not saying it will solve the problem, not at all - but it's a free solution to try out, no more, no less. Besides, I know plenty of people successfully running the latest Cubase under Win10 without issues, so that doesn't seem to be a universally valid concern, either.

I don't have any exact problems, either, but it's cleary sub-par (in terms of performance as well, I did a bunch of comparisons). Hence, I can pretty much imagine it to be at least part of the problem. While being far away from an ideal solution, it helped countless people to get rid of driver related issues and usually delivers better performance than what comes with many budget interfaces (usually a licensed, slightly adapted more or less generic driver from Thesycon). It's not even too unlikely that the underlying code under the hood is a better suitable one for some situations.

Your headphones work via Bluetooth and they're useless in this case, causing too much latency (delay). Besides, the Helix doesn't work as a Bluetooth transmitter. If you really want to have some fun with the Helix, you need a decent monitoring solution, headphones being your most affordable bet. In case money is an issue (well, it always is, isn't it...), you could check out those from Superlux. Most excellent value for money, the HD 681 comes in at around 20-30 bucks - and yes, while not excellent, they're *way* better than what the price might suggest. I have a pair of them as spares and IMO they're almost up to headphones around 5-10 x the price (I actually sometimes use them instead of others occasionally because they're pretty nice to wear). If you want at least more or less decent monitor speakers for a decent price, you might want to check out the Tannoy Reveal 402 or 502 (around 200 a pair), the often recommended JBL LSR 305 or maybe the IK Multimedia iLouds, the latter being extremely well suited for small spaces. Personally, I'd rather go for monitor speakers in the first place and grab some cheaper headphones for those situations when silent operation is key. If I had to wear headphones all the time, it'd drive me nuts.

Did you check out the ASIO4All driver instead of the Line 6 drivers? As unfortunate as it is, the Line 6 drivers are pretty bad. Under macOS (which is what I'm running), performance is better using native Core Audio support (with the Helix running as a class compliant USB device) compared to the Line 6 driver (both in terms of CPU usage and lowest possible latencies) and under Windows your best bet as an alternative would be ASIO4All. http://www.asio4all.org/

Basically what crusinion2 said. Had this happening three times as well, needed to boot in preset restore mode to get rid of the faulty one(s). I got over it because it didn't happen in a long while. There seems to be a certain connection between changing the "architecture" (routing, switch layouts) of complexed presets and the chances for a preset to get corrupted, especially when doing things on the unit itself (never happened to me when using HX Edit), but I wouldn't even remotely imply it's really like that as it simply didn't happen too often (and for me it was with 2.8x). My personal conclusions: - Don't change anything significant in important situations without a computer at hand. As in: parameter changes yes, anything else no. - Always do local backups once connected to a computer. Apart from that, while I perfectly understand the possible issues that may arise with complexed computing systems, it still leaves a little unsecure feeling here and there. In addition, I never had this happen before on any of my MFX devices (and I owned quite a plenty over the years). But then, none of them has even been remotely as complexed as the Helix, so I still understand things. Oh, fwiw, I'm not sure whether that helps at all, but I do some clean ups more or less regularly. Usually, I only need a mere handful of presets for my live duties and another handful for the rare occasions I'm recording without my own computer at hand, so I regularly export everything and consolidate both my needed presets and the corresponding IRs - the latter unfortunately still being a certain hassle, but as long as I keep my patches limited, it's ok. When done with that, I overwrite everything not needed with empty patches.

Fwiw, here's a list: Reset Options Helix Floor/LT Button Combination Description 2 LED light Fun 3 & 4 Test Mode 5 & 6 Global reset 7 & 8 Reset setlists to factory, Keep IRs 8 & 9 Reset setlists to factory, Clear IRs 9 & 10 Reset setlists to factory, Global reset, Clear IRs 10 & 11 Upgrades existing presets to latest format 11 & 12 Clear current preset 5 & 12 Clear setlists, clear IRs, Return system settings to default 6 & 12 Safe boot mode To use Reset Options: Power off the Helix Hold the desired button combination Power on the Helix Release the button combination

Did you try all of the various reset options?

Multiple selections would be great for moving things around, too.

I have no idea why it would necessarily be a benefit to have a high-z input without volume control. IMO and from my experience, it doesn't matter. And I still prefer to get a great leveled signal into my DAW, even if it was just for the waveform visibility aspect. In case there's too much level going into my modeling plugin of choice, there's plenty of ways to trim the signal down a bit. Some plugins (Helix Native included, but also true for Amplitube, Guitar Rig, etc.) have their own dedicated input trim control. Besides, out of the interfaces I owned during the last 2 decades (quite some...), not a single one had a high-z input without gain control. No idea what the L6 dude is refering to.

Let me put it that way: There might be situations when the differences might become very obvious - when they aren't in other situations. Usually, when fooling around with the volume knob of your guitar, the difference might be very very noticeable, way in favour of a true high-z input. Similar things go for certain drive pedal types, most notably of the fuzzy kind. But then, in case you like the sound as is, why not just do it that way? However, I'm wondering about the way your high-z input behaves. If done properly, such an input should be able to deal with any typical guitar signal just fine. Fwiw, in case you're using active pickups, you can basically use whatever you like, they're throwing out a low impedance signal already. Same goes for any active (or non true bypass) pedal in front of your interface.

Could you record some snipplets of the sound you're not happy with? Ideally along with: - A DI track (just your guitar as snagged from the Helix' USB 7/8 signal path). - A kind of description of what you don't like (and how you would like it instead). That way, people could a) get an idea of what might not be after your likings (verbal descriptions only go this far) and b) possibly have a go at some improvements.

I wouldn't happen to know why HXN wouldn't profit from gain reduction meters any less than any other unit featuring them (such as a compressor). In fact, I have already been wondering why they're not existing in HXN.

Dude, I have actually *proven* that the Stomp delivers pretty much exactly half the CPU power of the Floor - as in "scientifically proven". I actually could have deleted the guesswork paragraph but kept it for completeness (it was just a little sidestep speculation anyway, about why the Stomp could possibly deliver slightly less than half the CPU juice - which, in the end, it doesn't). The last paragraph was kinda like a "hold on, let me quickly try that" thing. Which is what I did.

As you're on Windows: Forget about HX Edit entirely for now. Don't start it again! In case it fails to connect to the Helix, it'll continue to run as a service in the background. This explains that you can't restart it. It also explains why using the Updater might be fruitless, because in case you've started it without rebooting your computer beforehand, HX Edit still running as a service in background will spoil the experience. So, you can now go to the task manager and kill the service, but if I were you, I'd simply reboot and not touch HX Edit at all but check the Updater straight away.

Oh right, didn't read carefully.

There seems to be a serious issue with your computer. These days, just turning off a connected device (pretty much regardless of what it's doing) should not crash a well configured computer.

Did you try the Line 6 Updater instead of HX Edit?

Well, I thought it was pretty much common sense. From all that is "officially" known, the Stomp seems to have half the processing power of the bigger units, so to me it absolutely makes sense to assume the block limit wouldn't be caused by DSP limitations but rather by design decisions. Now, there might be some more points to consider (plain guesswork on my part, but still), such as there being other tasks the DSP is needed for. Things such as controlling the audio interface portion, the I/O routing and what not. With the stomp, the CPU overhead caused by these might be somewhat higher than with the Floor. Also, due to the smaller size, maybe Line 6 doesn't want to get the CPU taxed as much because it might heat up too much otherwise. And yet, in the end we're talking 6 vs. 16 blocks, which is a *huge* difference - a difference that couldn't be justified by my speculation above. Someone owning both units could actually compare things quite easily by loading some the most CPU intensive blocks into either unit (which will easily bring the DSP of a single path on the Floor down to it's knees with just 3 blocks). Thinking about it, I could even try that myself with Helix Native in Stomp/Floor compatibility mode. Well, in fact, I just did so. HXN in Stomp compatibility mode is offering the same amount of CPU as a single path of the Helix Floor. And as HXN patches are 1:1 compatible with the respective hardware, it should be pretty clear that the block limit is *not* a result of DSP limitations. There we go, no guesswork at all, plain facts.

You're welcome.