Please ensure Javascript is enabled for purposes of website accessibility Jump to content

Bug Report: Snapshot settings not applied correctly in Snapshots


bbehrens
 Share

Recommended Posts

I have a Preset with 8 Snapshots. Snapshot 4 has an Heir Apparent turned on, while Snapshot 5 has a Kinky Boost, Heir Apparent, and Prize Drive turned on.

When the Preset is loaded Snapshot 1 is correct.

When Snapshot 2 is loaded, it is also correct.

When Snapshot 3 is loaded, it is also correct.

When Snapshot 4 is loaded, the Heir Apparent is not turned on in Stadium App or on the Stadium Unit (It should be on).

When Snapshot 5 is loaded, the Kinky Boost, Heir Apparent, and the Prize Drive are all off (They should be on).

Heir Apparent is turned on in Snapshot 4 and the preset is saved on the Helix Unit.

When Snapshot 5 is loaded, the Heir Apparent is on (This is an apparent carry-over from Snapshot 4).

The Kinky Boost and the Prize Drive are also turned on via the Helix Unit and the preset is saved again.

When Snapshot 4 is loaded, all 3 three Distortion blocks are now on in both the App and the Unit (An apparent carry-over from Snapshot 5).

When Snapshot 3 is loaded, all 3 distortion blocks are off, which is correct.

When Snapshot 4 is loaded, all 3 Distortion blocks are still off (An apparent carry over from Snapshot 3), However, the Stadium App now shows that the Heir Apparent block is turned on (conflicting with what the Helix Unit is showing).

When Snapshot 5 is loaded, all 3 distortion blocks are still off in the Helix Unit. However, the Stadium App shows all 3 turned on.

 

Factory Reset of the Unit, and Importing and Exporting the Snapshot will not resolve this issue. When the Snapshot is reloaded, this issue is reproducible.

 

Bug Report has been filed with Line 6.com

  • Like 1
Link to comment
Share on other sites

Appreciate the post... and that you opened a ticket with support. I have had a few issues with snapshots but when I started from scratch and rebuilt the preset, the issue was resolved. If I re-imported the old troublesome preset...the issue is there. Not sure if that helps for a workaround. 

Link to comment
Share on other sites

 

On 12/29/2025 at 4:47 AM, bverdon said:

Appreciate the post... and that you opened a ticket with support. I have had a few issues with snapshots but when I started from scratch and rebuilt the preset, the issue was resolved. If I re-imported the old troublesome preset...the issue is there. Not sure if that helps for a workaround. 

 

Yes, I rebuilt the Preset from scratch and it worked as expected. Saving and re-loading the original problematic Snapshot did not correct the issue as it continued to persist.

 

Interestingly, while re-building the preset, when I moved a few of the blocks to a parallel path (From Path B to Path B1 and B2, I ran out of DSP and could add no further blocks. So I discarded the edits and added the other blocks first and then moved the blocks that I wanted to the parallel paths and it worked fine. And I could no longer produce the DSP issue. It should be noted that I was operating very close to maxing out the Max DSP (whatever/wherever that is).

 

I am very interested in the DSP values as I have my own spreadsheet for the OG Helix where I have DSP values for every block in the OG Helix down to hundredths of a percentage and is very accurate. I don't think that any DSP values like this will happen any time soon for the Stadium as Line 6 takes some time so stabilize the DSP allocations on the OG Helix. Some of the 3.8.0 new blocks have the same MONO and STEREO DSP values and the MONO version were always optimized prior to 3.8.0. I think that they went off to do other things (Obviously). There is also the possibility that some DSP blocks may be more variable than the OG Helix was due to the new Agoura Amp models (though I think that it would be limited to the Amp/Cabinet combination and not the OG helix effects models and Legacy Amps.

Link to comment
Share on other sites

I’m wondering if this is related just to the editor/app. Are Snapshot changes consistently working properly if you just use the device, not the editor, to create and modify the Snapshots? Seems to be the case for @bverfon. Is it true for others?

 

I expect this won’t help with importing presets from OG Helix but it may give the developers more insight to identify and fix any related bugs.

Link to comment
Share on other sites

Just compared the file contents of the original (problematic) file with the second one I recreated from scratch and noticed that the snapshot settings for all of the blocks is populated with null after the first three Snapshots (which work correctly), instead of true or false as opposed to the Preset that is working properly. I did create the preset with the Stadium App (as that is still my preferred method) so I can not report whether it was the App or Stadium XL that created the problem. But once the preset is created with these null values then I think that it can not be corrected unless you edit the file (perilous and error-prone at best) or just re-create the Preset from scratch as @bverdon suggested. Either way, it is definitely a bug.

 

For further clarification: Original (problematic) Preset: the "snapshots" element is each block records "false, false, false, null, null, null, null, null"

The re-created Preset: the "snapshots" element is each block records "false, false, false, true, false, false, false, false"

 

I typically expect true/false to be binary unless there is another purpose being used for the value.

 

This would lead me to believe that those blocks are not being set properly and may either be turned on or off depending on the last snapshot loaded (or another internal array).

  • Like 2
Link to comment
Share on other sites

I'm not sure if this is the exact answer, but I ran into something like this.  Blocks weren't being turned on or off when changing Snapshots on a Preset I created.  I tend to edit on the HSXL I've found the current editor version a bit buggy, and the HSXL is so easy to work on.

 

On the HSXL, if you touch the Block you want to control, at the bottom of the Action Menu, there is a Snapshot Bypass switch. Switch that to On.

 

From the Manual:

Adjust the preset by doing one or more of the following:

  • Turn one or more effects on or off by pressing stomp mode footswitches or tapping their bypass icon

    The Bypass button
    . Snapshots remember every block’s on/off state

     

    • You can disable this behavior per block: Tap the selected block to open the Action Panel, then tap the Snapshot Bypass toggle OFF. When off, the block’s bypass state won’t change when switching snapshots.

Link to comment
Share on other sites

Thanks Mike. This functionality was present on the OG Helix. Unfortunately, the blocks were all created equal but act differently. Not sure what magic combination of button pushes did that but the footswitch bypass was not one of them (pretty sure unless it is easy to change without intending to). I have a hunch that the Stadium App is a little buggy under the covers. But if the code is much different than the code in the presets on the Unit then we will be chasing twice as many bugs through the system. Even worse if they ever get a Stadium Native interface going for DAW's. But that has not been Line 6's approach. They unified their development process back as of 3.0 (I think) of the OG Helix. And the OG Helix has been, and is still, solid.

 

I don't know when I will be able to use this new (more expensive) Stadium thingy. I don't run it like it was a plain vanilla pedal board.

Link to comment
Share on other sites

  • 2 weeks later...

I’m following this thread because the biggest issue right now appears to be snapshot inconsistency. It’s both the most important feature and, unfortunately, the most concerning bug at the moment.

 

Until this gets fixed, the most reliable workaround—although a bit time‑consuming—is to rebuild your patch from scratch.

 

I’ve also had decent success by creating a brand‑new preset (saving frequently) and then copying blocks over from the problematic patch one block at a time. Again, save often. Once all the blocks are in place, you can rebuild and configure your snapshots.

 

One thing I now do EVERY single time I create or update a snapshot is test each snapshot individually BEFORE saving the patch. This has helped me avoid corrupted or inconsistent states.

Link to comment
Share on other sites

On 12/30/2025 at 8:04 AM, silverhead said:

I’m wondering if this is related just to the editor/app. Are Snapshot changes consistently working properly if you just use the device, not the editor, to create and modify the Snapshots? Seems to be the case for @bverfon. Is it true for others?

 

I expect this won’t help with importing presets from OG Helix but it may give the developers more insight to identify and fix any related bugs.

 

I have had this issue and I just use the device for editing. It seems blocks can get into some odd state where snapshot changes don't save. I've had this happen a couple times but cannot reliably reproduce it. 

Link to comment
Share on other sites

I discovered this week that Snapshot Bypass switch is opposite - in my opinion. To turn the Bypass on, you need to switch it to the LEFT.  The state of the block will stay the same no matter what Snapshot you go to.  Putting it to the RIGHT - towards the Snapshot Bypass label, Snapshots will control the block. To me, switching TOWARDS the label would mean it would bypass - not be affected by a Snapshot change.

Link to comment
Share on other sites

I have one interesting observation which I just figured out today: I rebuilt my preset from scratch but I still had issues with blocks not reacting on the various snapshot settings. 

The issue is (only a guess) that Stadium has a problem with favorites. When I exhanged the favorite cab (with which I had the snapshot problem) with one of my non-default cabs it worked.
So maybe also the favorites has to be stored new?

Link to comment
Share on other sites

I have previously traced this issue to the underlying .hsp JSON file. I am not entirely sure, as I no longer develop these days, but I think that once the file is corrupted, it is not likely to self-correct and the file is permanently corrupted. This SHOULD be a very high priority issue for Line 6. But we must be patient as these types of tracking issues can be elusive, have multiple causes, and be hard to track down and correct. I have run into this issue still in v1.2.1, so it has not been entirely corrected as yet.

  • Thanks 1
Link to comment
Share on other sites

Hello everyone,

 

I’m having the same issue here. Rebuilding the preset from scratch didn’t fix it. I’m sharing the text of my support ticket below and will update this thread once I hear back from Line 6. Hopefully it helps others who are running into the same problem.

 

Best

    Ben

 

---

 

I believe I have encountered a reproducible snapshot recall bug on my Helix Stadium.

 

Here is the setup:

 

I created the preset from scratch using firmware 1.2.1.

Within the preset I use multiple delays and reverbs, including the CrissCross Delay block.

Snapshot Control is enabled for all CrissCross Delay parameters mentioned below.

 

Snapshot: “Dist | PM”

• Feedback A: 60%

• Feedback B: 70%

• Mix: 45%

 

Snapshot: “Dist | Rth”

• Feedback A: 30%

• Feedback B: 40%

• Mix: 25%

 

Expected behavior:

Each snapshot should recall and retain its own parameter values.

 

Actual behavior:

 

  1. I first set up “Dist | PM”, then “Dist | Rth” — everything works correctly.

  2. When switching from “Dist | Rth” to “Dist | PM” and then back to “Dist | Rth”:

    • The CrissCross Delay parameters in “Dist | Rth” are overwritten with the values from “Dist | PM”.

 

On the hardware screen, “Dist | Rth” now shows the wrong (PM) values.

On the macOS editor app, I still see the original correct values for “Dist | Rth”.

However, the audible result clearly follows the values shown on the hardware — not the app.

 

So it seems the device state is overriding the snapshot data, while the editor still displays the stored snapshot values.

 

I have not been able to resolve this by re-saving or rebuilding the preset. Since it was created from scratch on the current firmware, it doesn’t appear to be a legacy preset issue.

 

Please let me know if you would like a video, preset file, or step-by-step reproduction recording — I can provide one.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...