Virtual true bypass?

[MonkeyXT]

A quick note; installed FW 2.20 later last evening - seemed *knock on wood* to go smoothly.

The only issues are the ones which have chased me along from first thing; Function switch stomps and their flip-flopped LED status (lit when should be off) which I have to manually tap/touch to have it in the state I prefer, then re-save.

I've got quite a few of those...

 

My question is aimed at those in the deep-known; is there any reason to believe that the effects etc. blocks aren't 'true bypass' within Helix's sound paths?

 

Why I'm asking:

My 'catch-all' preset which I've been using since near to the beginning of my Helix experience last year is constructed wherein Path 1a is serial-fed into Path 2a. Meantime, both paths 1 and two have splits (to 1b and 2b respectively) to run some parallel blocks.

Typical stuff.

Path 1 has my main 'pre-amplifier' bits, plus amp1 with cabs 1a and 1b (for the sake of a naming them generically).

Then downstream, at the head of Path 2a I have amp2 with cabs 2a and 2b.

Path 2 continues on split to have parallel delay and reverb...

All is good; I've used that arrangement since before Snapshots, so it's all tied to function switches (TOUGH to fit some of that to 8 functions for 1 purpose...) - I'd been meaning to create a Snapshot version to see if I preferred that... finally did so before last weekend's sit-in gig.

 

Going back to when we were graced with the Litigator amp, I decided I'd make another duplicate of this patch, and simply swap out amp-and-cabs 2 to utilize the Litigator for that amp. Plus I'd dabbled in IR land, and found a couple which I liked coupled with the Litigator.

Sounded great in there; got along well with the rest of the signal chain.

Then I went to the primary sound - a very much clean sound - and checked it all out from head to toe again.

 

The clean sound was being affected negatively, though all the downstream blocks were off.

 

This was a direct substitution of just the amp and the two cabinets - tested with inbluilt cabs, and IRs.

In fact, the issue seemed worse with the IRs in place, even though they're off.

 

And, as was mentioned somewhere else by another user; changing something like the microphones of an inactive cab block gives audible artifacts as they 'flick' from one to another.

Odd for something that's off/inactive.

 

I tried re-building the patch from scratch.

Same result.

I tried other amps and cabs some had less/no effect on the bypassing sound; others seemed to suck some critical aspect of the sound away.

And again, no gain staging issues, etc.... and in case anyone's wondering; interrupting a signal path like this with a second amp in-line - and mono in nature - leaves the stereo aspect fully intact while those mono block(s) are inactive.

It only collapses to mono when those mono blocks are engaged.

 

So, anyone else run into anything like this?

 

[Verne-Bunsen]

I've wondered this myself. It's been my assumption, based on absolutely nothing empirical whatsoever, that bypassed blocks would be tone-neutral, but I'd be interested to hear from someone with nuts-n-bolts knowledge of the machine.

[MonkeyXT]

That absolutely has been my automatic assumption as well; that inactive blocks are invisible.

 

... but then, think about this; the first item in the sound chain will inform the input impedance value when it's on auto; I changed the order of my first two blocks, even though my original first block was inactive by default. When I swapped them, I could hear the difference, and I went to the input z and dialed it until what it read matched what I heard... and same test in original block order. Different values - even when the first active block being reached was the same in both cases.

I guess that's suggesting a path of investigation that could be considered closer to concrete...

 

 

Oddly I found that the negative effect on the sound was at its worst when I was using 2 IRs in parallel on the downstream Amp2 position.

Strange.

Maddening, also, as I had been trying to integrate Litigator plus IRs ... and using the same Litigator amp block feeding two onboard cabs was less of an issue, but still didn't compare well against my earlier version of the patch (which, if I recall, uses a well-tamed ENGL at Amp2 position).

 

I'm continuing to investigate.

 

(Meantime, with v2.20, I'm inclined to say that something has changed in the onboard cab handling; I was adjusting a cab block on a test patch, and found that it honed in and seemed to sound as good as any IR I've tried, by adjusting it in familiar ways... I arrived at what seemed to be a far better result while doing adjustments which were fairly typical for my part, that's what I'm getting at. As though it's improved in some fundamental way; the mic distance parameter in particular seemed to react more realistically to my ear.)

[MonkeyXT]

Just to update this; I sent up a flare to Frank about this topic and related findings.

This began a short chain of events which led to me, by request of Line 6 Support, submitting a couple of versions of a very important main preset of mine which demonstrates the oddities I've noted, plus my notes documenting my observations to Line 6 support / engineers - they opened a support ticket on this in order to track the discussion and findings.

Very impressed with the customer care approach.

 

I'll update this thread as information gets to me.

Cheers.

[jbuhajla]

Nice find, and nice feedback from Line6. Looking forward for the update on this. 

[MonkeyXT]

Thanks - and yes, I'm very curious as to what the feedback on this will be.

[FlyingsCool]

That absolutely has been my automatic assumption as well; that inactive blocks are invisible.

 

... but then, think about this; the first item in the sound chain will inform the input impedance value when it's on auto; I changed the order of my first two blocks, even though my original first block was inactive by default. When I swapped them, I could hear the difference, and I went to the input z and dialed it until what it read matched what I heard... and same test in original block order. Different values - even when the first active block being reached was the same in both cases.

 

....

 

This would be my expected, and hoped for, interaction experience.  If it's on auto, I'd expect that whether the first block is on OR off, that it would still drive the impendance.  Otherwise, the impedance might change when I switch it off and off.  It's also how it would work in the real world most likely... Whether the pedal was on or off, the impedance should be constant.

 

The first active block being the same though and showing differences.... That's weird.

 

IR's, I don't know how I feel about that one... That I would think should be true bypass when off.

[MusicLaw]

I'm interestingly following the developments of this topic, as well.

 

These may indeed fall within the scope of Line 6's constant ongoing improvements to the fw, signal chain, and interaction of the various blocks and models as they interact.

 

I would not expect an explicit white paper from Line 6 detailing any of what may turn out to be reworkings or improvements that may deploy in later fw versions.

 

It may be more likely that a short statement regarding overall improvement and optimization may appear. Perhaps, with a bit more context of depicting one or several particular areas addressed. For instance, something perhaps like a statement regarding an improvement that achieved a reduction of noise floor of the FX Loops, or improved depth and resolution of the Reverbs, or improvements to the mic characteristics as applied to the on board Cabs, etc. [Note: The above is mere speculation! In no way does it reflect any official Line 6 information.]

[MonkeyXT]

This would be my expected, and hoped for, interaction experience.  If it's on auto, I'd expect that whether the first block is on OR off, that it would still drive the impendance.  Otherwise, the impedance might change when I switch it off and off.  It's also how it would work in the real world most likely... Whether the pedal was on or off, the impedance should be constant.

 

The first active block being the same though and showing differences.... That's weird.

 

IR's, I don't know how I feel about that one... That I would think should be true bypass when off.

 

You're absolutely correct.

Re-reading, I realized that I had left out an important piece of the puzzle, which hopefully clarifies why I wouldn't expect that difference to appear - the two blocks I swapped were compressor (Red Squeeze), and an inactive gain block.

 

Of course I may be wrong here, but to my knowledge the volume block isn't an emulation of a physical pedal/device and its characteristics, but a simple insert to handle volume/gain level (in this case, an optional few dB of 'clean boost).

As such I would figure that the gain block would be very transparent and non-reactive - I wouldn't expect it to represent a load on the signal path, especially compared with the Red Squeeze.

 

Makes it more strange to me that there was a difference.

 

And the fact that putting that different amp and parallel cab setup 'downstream' had that negative affect on the sound when bypassed... I think that is the big issue - especially since, for whatever reason, when I put IRs in place of those two cabs, the degradation of the sound was more exaggerated.

 

Flicking through mic models on an inactive speaker block and hearing the audible repercussions of that - also strange. That observation came from another user here, and helped focus my observations.

 

Very curious what will come of this.

Good to know the team is investigating.

[MonkeyXT]

I just thought of a really interesting experiment I should try;

I should do a TRUE bypass of that area of the patch to see if it makes a difference...

 

Take a loop; put in a simple 'jumper' cable, in to out. Put the send block after my upstream amp; put the return AFTER the downstream amp...

[FlyingsCool]

Transparent or not, each block has to have a specified input impedance, I'm imagining they choose 1M for those.  I have seen effect impedance charts floating around that should give some idea of the differences across different effects.  When the input Guitar In-Z is set to auto, the guitar input will change when you swap different effects with different impedances. I'm imagining no matter what, as the impedance changes, you could hear an effect.  I have not done any testing, just basing this thought on what I've read and thinking about it logically.  Every block has an impedance affect I'm imagining.

[MonkeyXT]

Transparent or not, each block has to have a specified input impedance, I'm imagining they choose 1M for those.  I have seen effect impedance charts floating around that should give some idea of the differences across different effects.  When the input Guitar In-Z is set to auto, the guitar input will change when you swap different effects with different impedances. I'm imagining no matter what, as the impedance changes, you could hear an effect.  I have not done any testing, just basing this thought on what I've read and thinking about it logically.  Every block has an impedance affect I'm imagining.

 

Fair to say.

It's interesting throwing this about - I think in some way there's a tie-in to what's going on with my downstream scenario, which is why I've kept this aspect in the loop of the discussion (see what I did there, re; my above experiment I might try).

My thinking is that the amp downstream, though inactive, might be loading the audio path differently.

I've been withholding saying that until I got some more feedback to bounce off of - thanks for that.

Perhaps it's one of the realistic aspects which can be a 'wart,' but only in certain contexts like mine.

My signal flow is a bit too complicated to create two discreet paths to switch between - otherwise, that absolutely would be the solution, I feel quite certain of that.

I suspect it would potentially be a giant task in firmware reinvention, but the ability to choose when a block will be fully 'true-bypass' (as though it was in a non-buffered switcher system) would likely solve my downstream amp 'tone suck' issue...

Still just conjecture on my part... but the more we discuss it, the more plausible it seems.

 

In my mind I've been designing a new signal flow which uses the experiment I mentioned; using a hard-wired block to jump past the 'problem' second amp when it's not being used.

I think I'd have to use a pair of loops in order to keep stereo imaging intact (if required... I'd have to experiment with that - the stereo stuff really is after the amps...)

 

Just thinking out loud about this ... but it's intriguing.

[FlyingsCool]

Fair to say.

It's interesting throwing this about - I think in some way there's a tie-in to what's going on with my downstream scenario, which is why I've kept this aspect in the loop of the discussion (see what I did there, re; my above experiment I might try).

My thinking is that the amp downstream, though inactive, might be loading the audio path differently.

I've been withholding saying that until I got some more feedback to bounce off of - thanks for that.

Perhaps it's one of the realistic aspects which can be a 'wart,' but only in certain contexts like mine.

My signal flow is a bit too complicated to create two discreet paths to switch between - otherwise, that absolutely would be the solution, I feel quite certain of that.

I suspect it would potentially be a giant task in firmware reinvention, but the ability to choose when a block will be fully 'true-bypass' (as though it was in a non-buffered switcher system) would likely solve my downstream amp 'tone suck' issue...

Still just conjecture on my part... but the more we discuss it, the more plausible it seems.

 

In my mind I've been designing a new signal flow which uses the experiment I mentioned; using a hard-wired block to jump past the 'problem' second amp when it's not being used.

I think I'd have to use a pair of loops in order to keep stereo imaging intact (if required... I'd have to experiment with that - the stereo stuff really is after the amps...)

 

Just thinking out loud about this ... but it's intriguing.

 

Actually, I would bet they've definitely thought about your suggestion, but chose against it for the sake of simplicity, but that it still is possible to implement.

 

I got this chart from the POD HD Manual, I'm betting Helix's effects are set up in a similar manner.  In fact I think I've seen a Helix chart kicking around, but didn't take the time to dig deeply for it...

 

 

I was surprised only one of the Wah pedals had a modified input impedance, I thought they were low across the board pretty much...

[FlyingsCool]

Found this... Haven't read it yet http://community.avid.com/blogs/avid/archive/2010/04/06/the-truth-about-true-z.aspx

[FlyingsCool]

Here's a response from Ben Adrian regarding input impedance and Helix Native and Helix

 

"

 

solarplexus said: ↑

I have a question regarding the Helix Native: How will it deal with the transients of the guitar going DI into the interface? DI'ed guitars have different transient response than amped/mic'ed ones which makes it sometimes tricky to make it sound good with some amp sims, so I was wondering how the signal would be dealt with in the Native plugin, and how it actually is dealt with in the Helix hardware to make it sound the same on both software and hardware in the DAW?

Good morning (at least where I am),

Let me start by explaining the impedance switching/matching on Helix hardware (floor and rack). This switching is done in the analog domain. Before the guitar signal goes into the A/D converter, it is routed through an analog switching circuit that creates analog input networks of various impedance settings. This is not modeling, it's analog circuit reconfiguration. The point of doing this is to have actual analog interactions between the high impedance, magnetic guitar pickups and the physical, analog input circuit. This actual interaction is what has a bit part of shaping the transient response of the guitar.

Also, I want to mention, if a wireless system is used, it will interact the same as if a wireless system is used in front of a real amp or effect. Those will totally mess with the interaction of pickup to circuit to amp input, which is why Brian May puts his treble booster between his guitar output and wireless body pack input.

So, how will Helix Native handle this? Well, as far as I know, there won't be anything at all at release. Helix Native is, by definition, operating full int the digital domain. With Line 6 hardware we can control the full impedance interaction, but every audio interface has a different 1/4" input impedance. A transformer-based DI box has a totally different "feel" than a guitar amp input circuit.

Unfortunately, it's a silly, ridiculous, and nearly impossible task to try and tray every audio interface, measure its input impedance, and then try to digitally compensate for its character. My advice will be to use an audio interface with a guitar specific input. If a company is selling an interface aimed directly at guitarists then it probably will have a guitar in with the classic 1M input impedance. Something like a Fryette/VHT Valveulator or any other number of other tube or solid state buffers can help out. Heck, an old POD with a digital out and all processing turned off could be used as a guitar A/D. I believe many Line 6 interfaces are still available and they all have correctly loaded guitar inputs.

So yeah, the short version of the story is that when using any guitar amp plug in, its on the user's shoulders to handle the A/D conversion of the guitar signal. Still, it's something that we think about and have handled in the hardware version of Helix, and that we will consider in any future hardware products.

 

 

Mogmog said: ↑

If the real amp has two inputs (low -input 2 and high - input1), is the model based on the high input or low input?. Then, how to get to get the equivalent of using the other input?.

All amps are modeled on the high or 1 input. If you want 2 or low, then use a gain block to take 6dB off the signal, and change the inpu impedance to something lower; somewhere between 68k and 150k.

 

 

And from Digital Igloo

 

 

jmtaylor22 said: ↑

The Helix fuzz face has more gain and never cleans up, I haven't ever tried a fuzz face or clone that has that much gain in real life, I would be really curious what they modeled for that it is a very odd fuzz face emulation to me.

The Arbiter Fuzz Face has a very low input impedance that loads your guitar's pickups differently from other pedals. It should be the first block in your tone, and Input > Guitar In-Z should be set to 10k Ohm (or Auto, if it is indeed the first block on Path 1A).

Anyone with a real Arbiter Fuzz Face should place it first on their pedalboard too.

 

And from the release notes for 2.0

 

 

• Per Preset Guitar In Impedance—Global Settings > Ins/Outs > Guitar In Impedance has been moved to the Input > Multi and Input > Guitar In block and is now recalled per preset. It appears at Knob 4 as “Guitar In-Z.†Now that it’s on the Home page, you can assign a footswitch or snapshot to it and determine how your guitar’s pickups are loaded in real time. The default has been changed to “Auto.â€

 

(dt)

[MonkeyXT]

That's a whole pile of awesome information, right on point with this discussion.

Thanks for the chart, and the links, and the quotes - excellent information.

 

I've talked a good bit about input Z where Helix Native is concerned; I'd posted a suggestion/thought that Line 6 would probably do well with creating an input interface which would include the Helix hardware input circuitry - as above in the information, they've got a very effective analog circuit in there doing its thing to give us the 'feel' push/pull we are expecting from a non-sim signal path.

If they could duplicate this into a bit of a patch bay, that would be a marvellous device with applications that go beyond Helix Native, in truth.

(If they created a patch bay to give Native access to the loops etc as represented on the hardware, that would be a nice achievement... not necessarily 'logical' when talking about a plugin... but an interesting thought."

 

I'm really itching to do that loop experiment - though I believe I'll have issues fitting the loop blocks into my patch; it's a pretty full patch.

But I'm going to try.

[FlyingsCool]

Yeah, I thought it would be good to collect it in one place for reference, for myself even, later... I've been having issues using the Arbiter, and this may be why.... Can't wait to get home to test it...

 

This, to me, is really important information... I hope they develop an Advanced Users Guide someday similar to the one they created for the HD500X, plus an updated Model Guide would be useful to.  I've been creating my own version of the one that's in this thread.... Hopefully I can release it someday... Sadly, Helix updates are coming too fast for me to keep up  :blink:   

 

:D

[MonkeyXT]

Yeah, I thought it would be good to collect it in one place for reference, for myself even, later... I've been having issues using the Arbiter, and this may be why.... Can't wait to get home to test it...

 

This, to me, is really important information... I hope they develop an Advanced Users Guide someday similar to the one they created for the HD500X, plus an updated Model Guide would be useful to.  I've been creating my own version of the one that's in this thread.... Hopefully I can release it someday... Sadly, Helix updates are coming too fast for me to keep up  :blink:   

 

:D

 

I'd be happy to have that reference material, that's for sure.

I never did look at the HD500X User's Guide - I stopped at PODhd (bean). Truth was, I was sort of 'butt-hurt' that Line 6 wasn't going to do the 'X' upgrade to the Bean form factor (from what I gather, it simply wouldn't fit in the same general package size any longer...) and, though I kept hitting the CPU limitations over and over, I didn't want to go with a floor-based model. I've always preferred a separate controller (which is precisely why I have Helix Rack & Control).

The bean was my fave - still would be in fact.

At the time, though, my good friend Fulcrum called down to ask about the 'X' situation... and without saying so, the L6 person restored our hope by letting us know that they hadn't abandoned that market whatsoever, and in fact to 'wait for it' - a preliminary hint that Helix was coming.

 

Meantime, Line 6 Support just let me know a while ago that my patches and info had been passed on to the appropriate department.

I'm eager to hear back from them.

[FlyingsCool]

There's not a whole lot of difference between the HD500 and HD500X Advanced User Guide. 

 

I had (have, probably soon to sell it) the HD500 Bean, too.  Got it at an amazing price from Sweetwater along with an FBVII and case at an even more amazing price used from GC.  It was my first foray into Line 6 equipment.  I wanted to, but I never really used it a whole lot live, It was faster for me just to use the few pedals I had and my 3 channel amp to get all the sounds I wanted than to figure out all the various presets I would need to recreate those sounds and organize them to be useful for me when I played out, plus I tend to change stuff up on the fly, and HD500 interface wasn't great for that compared to turning on and off pedals at will and turning a couple knobs here and there.  But it was fun to use and I did use it quite a bit for practicing and writing and recording.  Form factor was good for carrying it around my house and even when I went on business trips I could take it and a guitar with me and play in my hotel room after work, and it worked well with my headphones so it was great when my kids were around and I didn't want to blast them out.  I just couldn't wrap my head around developing presets for use live (still having trouble with that concept with the Helix, but at least there's hope with 32 available slots.  It's a me thing, not a problem with Helix. I think it's just going to be a case of I just have to do it and it'll be fine (first gig with it out is on Tuesday at the Rockwood Stage 1 in NYC, 6(:30) pm)).

 

The only difference between the HD500 and HD500X was a little more available DSP so you could add a couple more effects than you could with the HD500.  I never really ran into a problem of running out of DSP so not having an HD500X bean didn't really annoy me.  It was already so crippled anyway in terms of I/O, I wouldn't have upgraded to another Bean anyway.  If I had upgraded it would have been to the floor model for the added I/O and loop (hence the upgrade to Helix).

[MonkeyXT]

There's not a whole lot of difference between the HD500 and HD500X Advanced User Guide. 

 

I had (have, probably soon to sell it) the HD500 Bean, too.  Got it at an amazing price from Sweetwater along with an FBVII and case at an even more amazing price used from GC.  It was my first foray into Line 6 equipment.  I wanted to, but I never really used it a whole lot live, It was faster for me just to use the few pedals I had and my 3 channel amp to get all the sounds I wanted than to figure out all the various presets I would need to recreate those sounds and organize them to be useful for me when I played out, plus I tend to change stuff up on the fly, and HD500 interface wasn't great for that compared to turning on and off pedals at will and turning a couple knobs here and there.  But it was fun to use and I did use it quite a bit for practicing and writing and recording.  Form factor was good for carrying it around my house and even when I went on business trips I could take it and a guitar with me and play in my hotel room after work, and it worked well with my headphones so it was great when my kids were around and I didn't want to blast them out.  I just couldn't wrap my head around developing presets for use live (still having trouble with that concept with the Helix, but at least there's hope with 32 available slots.  It's a me thing, not a problem with Helix. I think it's just going to be a case of I just have to do it and it'll be fine (first gig with it out is on Tuesday in at the Rockwood Stage 1 in NYC, 6(:30) pm)).

 

The only difference between the HD500 and HD500X was a little more available DSP so you could add a couple more effects than you could with the HD500.  I never really ran into a problem of running out of DSP so not having an HD500X bean didn't really annoy me.  It was already so crippled anyway in terms of I/O, I wouldn't have upgraded to another Bean anyway.  If I had upgraded it would have been to the floor model for the added I/O and loop (hence the upgrade to Helix).

 

Interesting.

I gigged my PODhd bean a fair bit (my gigs are very small affairs, and just sit-ins for me, technically... but I treat every situation like it's a stadium full of people.

For my part, PODhd is loaded with available capability, but was handicapped by the lack of processing power to take advantage of all the massive available options (dual amps etc).

I ran into that 'out of DSP' warning many many times. The release of the PODHDX made a lot of sense; largely the same device, but with the horsepower behind it to make full use of the capabilities built in.

I keep my PODhd rig handy as my back-up, just in case.

But, once you start using a Helix, you start looking at what you were using before in a new 'relative' context - but with that said, I was - and am still - quite happy with the sounds I get from my PODhd. It's good to know I've got that complete PODhd/shortboard/EX1 set-up ready to go.

In fact, I had a complete duplicate of that as well - always leaving the one packed and ready to go, the other at my music/computer area ready to use there.

I only traded away that second PODhd rig because of Helix.

I keep a PODX3 attached to my guitar work-bench as my test sound-maker etc.

I started with POD2, then PODxt, PODX3, PODhd.... then a gap as I bit my lip with anticipation while awaiting what turned out to be Helix.

Whole new quantum level, but with enough familiar Line 6 panache to make it easy to dive in and start making sounds.

 

I use zero outboard gear; just expression pedals attached to the control board, and a wireless (G50 for gigging, G10 at home), my guitar(s), and away I go.

 

I do feel that I should've delved deeper into the impedance characteristics more with PODhd - I have a feeling I would have fared even better...

I also feel that it's likely more of a 'thing' with Helix - the advancement of the technology that they're using to describe the fascinating push/pull world of music system signal paths and amps is so much more 'real' in comparison as Line 6 continues to hone their skills and push the modelling envelope.

That chart above is very enlightening.

[FlyingsCool]

BTW, I saw a post from DI implying that the impedance of the Arbiter is 10K ohms.  I'll have to look for the full list of Helix effect impedances.  I think I've seen it before (maybe not).

[FlyingsCool]

That's a good point.  Maybe I should keep and prep my bean as a backup system.  It certainly would be a heck of a lot lighter and easier to set up than my amp and pedals in the case of a Helix failure.

 

(BTW, don't think I'm any kind of real pro.  My SO is,... for some reason she likes to play out with me, despite my limited skills.... I'm an Engineer by day)

[FlyingsCool]

p.s. here's another thread on the subject http://line6.com/support/topic/20353-guitar-impedance-setting/

 

Your impedance thoughts are discussed in detail by DI and phil_m.  It was started pre 2.0, but continues on past that update...

[MonkeyXT]

That's a good point.  Maybe I should keep and prep my bean as a backup system.  It certainly would be a heck of a lot lighter and easier to set up than my amp and pedals in the case of a Helix failure.

 

(BTW, don't think I'm any kind of real pro.  My SO is,... for some reason she likes to play out with me, despite my limited skills.... I'm an Engineer by day)

 

That's your perception of what you are; that's fair.

I have my thoughts as to what I am as well, but I don't want to be a 'downer' here =]

 

However, clearly you have two very important elements which speak directly to this topic (and doubtless, many others); ears sensitive to what's going on, and an engineer's mindset analyzing the information at hand.

Your comments and references to other related info and topics has been immensely helpful in moving this discussion forward and in extremely useful directions.

So, to paraphrase, you've got that going on =]

 

 

p.s. here's another thread on the subject http://line6.com/support/topic/20353-guitar-impedance-setting/

 

Your impedance thoughts are discussed in detail by DI and phil_m.  It was started pre 2.0, but continues on past that update...

 

Thanks!

I just read through that, and gives many data points. I missed that discussion at the time, it seems... but it's the same food we're pondering here as well.

A worthy read; and interesting to relive that point where the input Z went from global to per-preset.

The person with the loop has a very interesting point about how that interacts...

 

Much food for thought.

[MonkeyXT]

I received a response via my Support Ticket today; essentially, it states that there's no way a bypassed block would have any effect on the sound. It's stated that this has been tested and found to be true.

 

The response leaves me open to pose questions, which I will.

But I have to say, my ears certainly disagree with this finding - as well as my trusted friend, who noted an audible different immediately on my demonstration of my observations.

 

I REALLY need to do that hard-wired loop bypass experiment.

And I'm forming various questions to try to dig into this a bit further.

Far be it for me to 'challenge' the engineers responsible for Helix - but I feel quite certain that /something/ is going on in the background of the signal path which may account for whatever it is I'm hearing.

... I'd hate to think the cheese has slid off my cracker in this matter, but I'm willing to consider the possibility.

 

... but I gigged one of the 'compromise' test patches, and found my sound to be lackluster that evening.. and it was the same venue at which I did my FIRST (and extremely satisfying in terms of sounds/ease of use) gig using Helix.

[rd2rk]

I realize that this thread is a bit old, but I'm felling a bit dense on this subject, and need the simple definitive answer.

 

I'm using a G10 wireless exclusively these days. My understanding is that the G10 loads the pickups at 1M, therefore it's OK to leave the default Helix setting at AUTO, as nothing else matters beyond that first device (the G10).

 

Yes or no?

[MonkeyXT]

No, in that the Auto setting is reactive to the first processing block in the internal signal path, whatever that might be.

That first processing block will inform that 'auto' setting of what value it should change the input-z to.

And that informs the impedance characteristic from there onward.

[zooey]

I'd think that the output impedence of the G10 would be low enough that the input impedence of the Helix itself wouldn't matter. Same for the active buffer in my guitar, but I haven't tested that, yet.

 

Can anyone say definitively if that's actually true or not?

[CraigGT]

This would be my expected, and hoped for, interaction experience. If it's on auto, I'd expect that whether the first block is on OR off, that it would still drive the impendance. Otherwise, the impedance might change when I switch it off and off. It's also how it would work in the real world most likely... Whether the pedal was on or off, the impedance should be constant.

 

Not necessarily, if the first pedal had a true metallic bypass (either footswitch or relay) then the guitar would see the input impedence of the second pedal in the chain when the first was bypassed.

 

Craig