zooey

Try a different USB port. Sounds weird, but only one of the three on my laptop work reliably with Helix, though they're fine for everything else.

Bias and BiasX are key, like seriously, for most Helix amps.

I don't mean to be argumentative, and of course you know something about Helix internals and firmware and I completely don't, but I don't get those logics, especially the "every possible combination" part... With all the complex and horsepower-demanding audio-rate stuff Helix does, checking in signal-chain order for the first enabled block and using its impedance doesn't seem like a huge cpu drain, or that intense to code Far as clicks and switching delay go, we can already control the same impedance-changing circuitry via any of the mechanisms you mentioned, so the side effects of doing that can't be that horrible A global setting for whether Helix should try to do any of this would let users who find any downsides objectionable opt out, back to the world as is its today The only flies I see in that ointment (outside of priority juggling, about which no comment) are: The two paths might be in parallelJust doubles the (I hypothesize) fairly trivial first-active-block calculation, and adds the basic math to combine them There might be splits and merges, some of which may mix between two blocks, possibly dynamically This is the only real conundrum in my book, and might be why you're backing away from this whole thing I personally think it could get short-circuited by some simplified logic, for instance maybe, if the first-active-block logic hits a block like this without finding one... Pick the higher impedance of the two blocks, or the lower of them, L6 to experiment and decide Average them Give up and use the input block impedance In any case, I'd hate to see this whole basically simple train of thought get derailed by that one tricky topology Make sense?

Bigger question I think is the resolution of the frequency control. If it had a finite number of steps, they'd be much further apart if the range was way wider, unless they added a new Range parameter. There's also the related question of backwards compatibility. All that goes away if controls can have arbitrarily wide ranges, but resolution could still be an issue in the UI

Can't say as I have, but just add in another parametric block, they're not that CPU intensive.

If you have one you think is bent, please send it to Support, so they can learn from it. Also, just for the nubbins, post it here, to see if it acts up for others too. And also because I'd like to see it myself. I'm working very part time on an IR inventory app, that among other things has to read preset files, and it'd be good for me to see how one might get twisted.

That doesn't only happen because we got new amps, at least for me. For reasons I have no idea of, I'll just really like one amp for a while, then a different one, yadda yadda. Sometimes I go back to ones I dug but haven't played for a while and love em, sometimes it's more like what was I thinking. Lucky I don't have to actually Grow Up or anything. Pretty much way to late for that anyway...

Yes. But still...

Agree, and not just mics, low and high filters especially. You want to compare the SPEAKERS, not their default settings. Ideally maybe, there should be a global setting for this. Sometimes you might actually want to hear what Line 6 thought was "recommended", if the defaults should be interpreted that way.

Post before yours was from today though...

At this point, I'd contact Support. Since I know you're super busy, arrange a loaner if possible (ping Frank, he's the man), and send it back. It's supposed to just work, and mostly it does, but not yours.

Victor, I think we may have a terminology problem. I keep thinking we're on the same page, then you throw in these "it's not about bypass" lines, and I'm confused again about what you mean. Do I understand correctly that you consider it to be a problem that Helix reads the impedance of the first block, whether it's active or not? Or in my terminology, "bypassed" or not? If so, then the problem is how Helix treats blocks that are "bypassed", i.e., not active, and in that sense it most definitely IS about bypass, at least what I mean by bypass. Can you agree with that, terminology aside? If I've got that right, great, I'm fine with different folks using different words for the same thing, though I have to say it is more than a little confusing in this case. If you mean something different than that, please try once more make it clear. I'm about ready to give up (not that anyone gives a hoot about that). I've been around this same block so many times with you. I've read this and other related threads all the way through. I've tried multiple times to be as clear as I can about what I think the issue is, and some possible solutions. I see comments from others that make perfect sense to me based on my understanding of what we're talking about. But then you throw out another "it's not about bypass", and I just want to stop reading this thread, I'm so frustrated and confused. There's a real problem here, but it's getting so muddied up, by us, I can't imagine Line 6 or people just coming into this thread now doing anything other than permanently ignoring it, which would be a shame. Just to be clear, I'm 100% NOT criticizing you. I'm sure you're talking about something real, I'm just not following what you're saying. Maybe. Or maybe I am, just using different words.

http://line6.com/events/tonemadepro/ It's listed in that GC's events too, so most likely they know about it and it'll actually happen :) I'm planning to go, unless something goes sideways. Anyone else?

Some correction and/or elaboration is needed I fear... The global impedance tracking setting proposed above may change the tone of ALL your presets at once, a pretty big deal. It's probably better to make it per preset, so you can migrate or reconsider your patches gradually. Same deal with having individual blocks suddenly adopt new input impedance and/or bypass behavior by default. That says the new settings have to default to the current behavior, whether it was the same as the analog original or not. Following the original is a nice idea, but changing the sound of everyone's presets is not.

^^^ This. So as mentioned many pages ago, the ultimate solution is three enhancements: Add a global setting for whether Helix's input impedance should be set by the first ACTIVE block, or the first block in the chain, whether it's active or not Add Input Impedance as a parameter for all block types, or at least stomps, defaulted to the real-world impedance of the real-world device if one exists, otherwise whatever sounds best to the designer Add Bypass Mode as a parameter for all block types, choices being the ones listed by Rebel420, True, Buffered, and Traditional Just to point out, adding impedance and bypass settings for all block types, not just "stomps" (whatever that means exactly), would let you do things like this: Switch on a fuzz with an EQ before it with one footswitch, and set the impedance of the EQ to match the fuzz, so the guitar gets loaded like the fuzz would, but still gets EQ'd first. As to whether that's too techie for us lowly guitarists, I'd vote no, it's not, for people who are already using a pretty sophisticated modeler anyway.

Sorry, I'm not getting what exactly you're seeing. Post a pic maybe? When you say you can't turn stomps on and off, do you mean with the footswitches, the UI, both? Can you turn things besides stomp fx on and off, or is it every type of block?

Sure, Action button, works fine across presets. Only caveat is that copy-paste doesn't work very well when snapshots are in play. I'd prefer if it just copied from the current snapshot, and pasted into the current snapshot, left others alone. Kind of a pita to do w multiple snapshots you care about, but since they might not be laid out the same in the source and destination patches, there's really no other constructive option. Really, it'd be best if it could ask you if you want to paste from and to all snapshots, or just the current one.

You have a multitrack from those sessions? Where did you get that?

To get a mix of the tones of two different cabs.

First I've heard of this. When you say it's known, does that mean you have a sequence of steps to reproduce it? Otherwise known as steps we should NOT take if we DON'T want that to happen...

#2. And try to build your patches at love volume and through the speakers you'll be using.

^^^ This.

Back in the day, "true bypass" just meant using a double pole double throw switch to directly connect the input to the output, and at the same time disconnect the guitar from the circuit input, so it didn't get loaded down when you weren't using the pedal. Not rocket science, just doing the extra work so the pedal's guts are completely out of the picture, like it wasn't there at all. That's the fundamental question here: Does a pedal that's off still load the guitar, or does it pass the loading question on to the next block in the chain. "Buffered bypass" may be a thing in the real world, to actively prevent downstream pedals from loading the guitar, even when this one pedal is off, but nobody's proposing modeling that behavior.

Victor, apologies if I'm being stupid, but how is this NOT about true bypass? A real-world pedal's circuitry has a given input impedance. It clearly affects the response of the guitar when the effect is on, but if it's true bypass and turned off, its circuitry isn't connected to the guitar at all, so its impedance is totally irrelevant. I completely agree that the current behavior is wrong, and as I said, I don't think the fancier options I detailed are worth Line 6 building, or us users having to deal with them, but the fact remains that those do seem to me like the available choices.

Don't agree with the bolded part. Helix doesn't have the concept of a true bypass pedal, or one that loads the guitar differently when it's on vs off. Option 1: Two additional parameters for each block: - Input impedance when off - Input impedance when on Setting them both the same would be like Helix is today, loads the guitar the same on or off. Setting the Off value to 1M and On to a lower one would be like true bypass. Option 2: All blocks have their real-world impedances built in, and we'd get only a setting for whether it should act like true bypass or not, i.e., not load the guitar when it's off, or load it always. Option 3: A single global setting to turn true bypass behavior on or off for all pedals at once. Option 4: Don't add any new parameters, but use true bypass behavior (no loading when off) for pedals that do that in the real world. None of this is "authentic" though, because Helix can only change the initial input impedance the guitar sees. In reality all devices have both input and output impedance, which interact in some fashion all the way down the chain. That would need to be implemented in software, no way it's worth the effort IMO. I vote for option 3, a single global "true bypass" setting.