MonkeyXT

Happy to help.

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.

No reason it shouldn't work the same; it's the very same screen.

This is probably a direct relation to the stomp switch lag, which is a confirmed bug that is being worked on by the Helix team. Your description is likely exactly what's happening; a stepped, cascading kind of switching. Watch for the next firmware (expected to be v2.21) upcoming; your issue will likely vanish with that. I also recommend Snapshot mode to do this switching - perhaps try this by duplicating your preset, and work it out to do the switching that way. I have an important preset which predates Snapshots, so my method is exactly as yours above - stomp switch swapping amps etc. What I found when I did a test version using Snapshots to do the switching was that it was a smoother switch - no audible artifacts. (I happen to think that the order in which you assign the changes to the stomp switch is important, in the smaller-details world; I stack them so that there's less likely to be noise, and that seems to work).

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.

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...

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.

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

Great example of Frank and the team's dedication. I've been immensely impressed with this aspect as well; Frank has been very active - proactive really - in tackling things which are brought to his attention. I'm actually in the midst of a support ticket (which really is more of a 'bug report' type scenario, but the support team chose to open a ticket, likely to track the subject and communications traded, plus the files I've uploaded for analysis by the L6 Engineers. It was Frank who ran with the ball on that one, and made certain to contact me directly by PM in order to update me. This also has been the case with regards to the bug in v2.20 which has caused the stomp-mode switches to become sluggish in response (see other thread for that discussion) - Frank contacted me /very/ soon after, letting me know that he'd brought this to the attention to the Helix team, and that they had in fact identified the bug and were working toward a fix, which is intended to be in a maintenance release, v2.21. So, I am very glad to see this topic having been posted - thanks for doing so, zooey. And also, glad Line 6 got you sorted out, and so amazingly quickly. Cheers!

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.

I'm 50, and have been using Line 6 to create my sound since 2000 - 17 years to date, and counting. It's a brave new world, but Helix 'makes sense' in how it works in most aspects, so you will be up and running with it in no time. Plus the resources available like this forum, YouTube videos... lots out there to help. But nothing is better than sitting and dialing the dials yourself, to see and feel the results. Happy Helix-ing (it's now a verb!)

I do this by running the second amp downstream on path 2a, with the first (clean) amp on 1a. I was doing this prior to Snapshots; I had a multi-assigned function switch (maxed out to 8 items =]) which selected between the two. We're quite lucky in that Line 6 made Helix so that stereo isn't collapsed by the second mono amp when it's not an active block: any stereo effects coming from upstream (path 1a/b) maintain their stereo image.

The Ultralite isn't padded; it's a material (like carbon fiber) which is super-light (was meant to combat flutter, ironically - since both Steve Vai and Satch were involved with the creation of the Ultralite bar - I think Steve is still favouring one of the aluminum sleeved prototypes on one of his performance guitars - and they've both got lots of history with making use of the flutter effect in compositions). I have added padding to my Jem7VWH bar, in fact - I used a long-discontinued sleeve that Ibanez used to have in its product lineup. I think it was called the Suregrip. I padded mine to ADD mass, to INCREASE flutter potential =]

I like that; indefensible amounts of time... That's the very heart of creativity; pushing the boundaries to some degree, both small and large - gateway to innovation. ... or some horrendous but well-earned noise =] I re-examined my 'super-patch' for my small live performance purposes; it's the product of the very first thing I worked toward once I got my Helix Rack/Control. I did this because I was finally ready to sit down and make a Snapshot version of that super preset. ... and for the life of me, I can't recall exactly how/why I went about adding in some of the little elements into it, and /where/ in the path... but darned if they don't ruin the sound if I remove them =] (Notable exceptions; I was running into the 8-elements per control stomp switch assignments before getting every single thing I wanted to accomplish done... so I 'compromised' on a couple of details. Now that I've got a Snapshots version or three (!), that ceiling was /MASSIVELY/ elevated, so I was able to make those little niggling changes.)

I've done this before, and it was a decent result. I forget what the combination was at the moment. However, as I recall, I don't think it was groundbreaking for me enough to change to doing that all the time. But... this makes me want to revisit this again. I think I've gotten HUGE mileage out of the Minotaur drive block... that is a highly nuanced model (I've never tried one of the 'real' pedals) which can do a wide range of drive textures. I have this feeling that the existing drive effects on hand probably made me decide not to worry about the more 'expensive' DPS requirements of the full-on preamp... But, I'm going to revisit anyway; you have piqued my curiousity.

I'm chiming in to remind myself to do an experiment/test with this when I'm next in front of my Helix - so I can see if there's an issue in assigning these functions in the current firmware version. I'll chime in again once I've done that.

Excuse OT - which Jem model? (I'm curious as a fan of the model - I'm an owner as well)

Did you take note of your global settings before installing the update? If you'd changed the level settings of the outputs, and the installation's defaults are different, it could account for that symptom.

... I realized why after; I was mentioning based on an email notification I received. Upon visiting TGP, I discovered that he had PMd me that info - not that it's a secret. I guess he just wanted to target the info at me. I confirmed with him that there's no issue with spreading the word about this, as I'd already been doing =] Hopefully they're tracking other issues people have noted as well.

Gotcha. I'll try to duplicate this

Regarding the stomp mode lag; Frank Ritchotte has stated outright on The Gear Page that a v2.21 bug fix update is coming which addresses this; they found the issue and are correcting. He actually stated we should see "better speed across the board" - sounds like some nice optimizing. I'm not certain what other fixes are to be included in this update - just relaying what he posted directly to me on TGP. Excellent - I'm ok with doing the upgrade procedure again to address this, especially knowing that a more efficient update methodology is on the horizon for us.

I have had a couple of freeze-ups when scrolling away from then back to a particular preset (a very stripped down simple one; the most 'sophisticated' aspect of it is that it has a Solo lead channel amp feeding two IRs in parallel...) I have yet to go back to that to see. I'm going to do some scrolling to see if I get the audio dropouts as well.

Indeed. I tested that out as well, in case that's what you meant. I couldn't duplicate it. I wonder what the variance is from one Helix to another which causes some of these bugs to show up in some but not all units? Can you post a patch that misbehaves this way so that one of us can load it and see what we get?

As a data point: I tried every which way to recreate this; couldn't do so. (Two single cabs on parallel paths, then a dual-cab block - was getting processed signal in all cases) I'm also on v2.20, using Helix Rack/Control.

Have a look into the bug report thread; we're discussing this in there.