Question re adding a new block to existing patch with many snapshots set up. I want new block to be OFF by default on ALL snapshots unless I decide otherwise.

[d0stenning]

RE Presets with many snapshots set up: If I add a new block - say Ganymede - the bypass-state for that block stays always ON for all snapshots, even if I turn the the bypass OFF for that reverb block before saving the preset.

I would like to - eg. for experimentation - insert a Ganymede block into some of my patches that have 4 or 8 snapshots, but have that Ganymede block by default be OFF for all snapshots unless I choose to include it in a particular snapshot. Up to now I have to laboriously go though each snapshot - one by one - turning off the block then saving that snapshot.

Is this something for an IdeaScale or is there a way round this?

[silverhead]

When you add the reverb block do not assign it to the snapshot controller. Turn it OFF and save the preset. Since it is not assigned to the snapshot controller it should now be OFF in all snapshots. Later, if you want it on in a particular snapshot, assign it to the snapshot controller and turn it ON only in the one snapshot. Save the preset.

[d0stenning]

15 minutes ago, silverhead said:

When you add the reverb block do not assign it to the snapshot controller. Turn it OFF and save the preset. Since it is not assigned to the snapshot controller it should now be OFF in all snapshots. Later, if you want it on in a particular snapshot, assign it to the snapshot controller and turn it ON only in the one snapshot. Save the preset.

 

That doesn't work.    I've tried exactly that. 

[d0stenning]

Here's an IdeaScale for this: 

 

https://line6.ideascale.com/a/dtd/Option-2-prevent-existing-snapshots-saving-new-block-in-ON-state/934538-23508?submitted=1#idea-tab-comments

[silverhead]

22 minutes ago, d0stenning said:

 

That doesn't work.    I've tried exactly that. 

You're right. Sorry for the misinformation; FX blocks themselves are always 'assigned' to the snapshot controller. Their parameters need to be specifically assigned to the controller but the On/Off state of the block is part of every snapshot. This is true even of the first block added to an empty preset where no snapshots have yet been customized. The preset still has 8 identical snapshots, all of them with the one and only block ON. This remains true with the addition of every new block in the preset.

 

EDIT: After a bit more reflection I'm not sure that Ideascale suggestion will get a lot of support. Seems it boils down to the default on/off state of any block when added to a preset. Should it be On or Off when you add it? Seems to me that in the vast majority of situations you're adding it because you want to use it, which means it should be On. Changing the default to Off (which with the current design would seem to be the way to achieve what you want) would be counter-productive about 99% of the time.

 

 

 

[pilottes]

It would make a lot of sense. Another idiosyncrasis...

[phil_m]

It's a lot easier to deal with if you have the Snapshots Edit parameter set to Recall rather than Discard. Than you don't have to re-save after making the change in each snapshot.

[HonestOpinion]

4 hours ago, d0stenning said:

RE Presets with many snapshots set up: If I add a new block - say Ganymede - the bypass-state for that block stays always ON for all snapshots, even if I turn the the bypass OFF for that reverb block before saving the preset.

I would like to - eg. for experimentation - insert a Ganymede block into some of my patches that have 4 or 8 snapshots, but have that Ganymede block by default be OFF for all snapshots unless I choose to include it in a particular snapshot. Up to now I have to laboriously go though each snapshot - one by one - turning off the block then saving that snapshot.

Is this something for an IdeaScale or is there a way round this?

 

I agree this has always been a bit of a pain and I would say quite often a block gets added that you only want active in one or two snapshots. The easiest way to do this I find is to make sure you are in snapshot#1 when you add the block, bypass it, and then save. This should leave it bypassed in the rest of your snapshots. But....

 

I think there may be a bug, at least on my Helix (firmware 2.60). When I do this in Snap/Stomp mode with for example four snapshots showing on my top row, stomps on the bottom row, the 4th thru 8th snapshots always seems to have the block state active, even if I set and saved it to be bypassed in snapshot#1. Snapshots #1 thru #3 have the block bypassed as I would expect. If I have the global preferences set to show all eight snapshots on the footswitches, then it improperly sets the bypassed block active only in snapshot #8. Kinda weird.  Btw, make sure you have the editor dialed up when you test this so you can see what is happening in snapshots #4 thru #8, even if you are using for example a Snap/Stomp setting on the Helix. Important Note: This testing was done with 'Snapshot Edits' = "Discard"

 

In other words, as long as you add the new block in snapshot#1 and set it to bypass, its block state gets saved correctly in every other snapshot except for the last one showing on your footswitches setup thru to the last. In a stomp/snap setup, if you bypassed the block, that means that snapshot#4 thru #8 is always wrong and in all 8 snapshots footswitch mode that means snapshot#8 is always wrong. Anyone else seeing this bug?

 

Summary: I don't think the global settings for footswitch mode('Preset Mode Switches'),  and possibly the 'Snapshot Settings' as well, are interacting properly with block active/bypass state when doing preset design.  I think there is a bug where the 'Global Settings' --> Footswitches --> 'Preset Mode Switches' setting (Snapshots, Snap/Stomp, etc.) is interacting with how the active/bypass state is being saved in snapshots. The 'Preset Mode Switches' setting should not have any effect on a block's active/bypass state when saving presets or snapshots.

 

Also, although your Preferences --> 'Snapshot Edits' setting(Recall, Discard) setting can and should have an impact on how snapshots are saved as per design, there is a possibility this behavior may also be interacting in unexpected ways with block active/bypass states.  I have not run the above tests with 'Snapshot Settings' ="Recall" so I am not sure if results will vary depending on how this global setting interacts with the 'Preset Mode Switches' setting.

 

WORKAROUND: So, at least for right now the workaround if you want all your snapshots to inherit the bypass state of a newly added block is to set 'Global Settings' --> Footswitches --> 'Preset Mode Switches' = "Snaphots", at least for the duration of your preset design session. Make sure you are in snapshot#1 before you add your new block, bypass it, and save. Now go to snapshot #8 and bypass the block and save.

[Doug6String]

4 hours ago, d0stenning said:

RE Presets with many snapshots set up: If I add a new block - say Ganymede - the bypass-state for that block stays always ON for all snapshots, even if I turn the the bypass OFF for that reverb block before saving the preset.

I would like to - eg. for experimentation - insert a Ganymede block into some of my patches that have 4 or 8 snapshots, but have that Ganymede block by default be OFF for all snapshots unless I choose to include it in a particular snapshot. Up to now I have to laboriously go though each snapshot - one by one - turning off the block then saving that snapshot.

Is this something for an IdeaScale or is there a way round this?

I'm annoyed by the same thing!  If I put the new block in any other preset, turn it off and then copy and paste it into the preset I want it in, the default state is off for all snapshots.

[jbuhajla]

I do LOVE snapsnots, but I have transitioned away from them just because of the lack of easy/flexibility. I use 8 stomps primarily now on one main template preset, then I customize the stomps for particular blocks bypass and physical stomp layout. I prefer stomps because we may change directions mid song and stomps allow more flexibility to change during the song. Stomps give me more artistic flexibility. I do use a preset per song, but the presets are just different stomp layout of the same preset, with custom tempo. I have the left up/down set to preset so I just scroll up when playing through the setlist. 

[HonestOpinion]

On 7/26/2018 at 2:54 PM, HonestOpinion said:

 

I agree this has always been a bit of a pain and I would say quite often a block gets added that you only want active in one or two snapshots. The easiest way to do this I find is to make sure you are in snapshot#1 when you add the block, bypass it, and then save. This should leave it bypassed in the rest of your snapshots. But....

 

I think there may be a bug, at least on my Helix (firmware 2.60). When I do this in Snap/Stomp mode with for example four snapshots showing on my top row, stomps on the bottom row, the 4th thru 8th snapshots always seems to have the block state active, even if I set and saved it to be bypassed in snapshot#1. Snapshots #1 thru #3 have the block bypassed as I would expect. If I have the global preferences set to show all eight snapshots on the footswitches, then it improperly sets the bypassed block active only in snapshot #8. Kinda weird.  Btw, make sure you have the editor dialed up when you test this so you can see what is happening in snapshots #4 thru #8, even if you are using for example a Snap/Stomp setting on the Helix. Important Note: This testing was done with 'Snapshot Edits' = "Discard"

 

In other words, as long as you add the new block in snapshot#1 and set it to bypass, its block state gets saved correctly in every other snapshot except for the last one showing on your footswitches setup thru to the last. In a stomp/snap setup, if you bypassed the block, that means that snapshot#4 thru #8 is always wrong and in all 8 snapshots footswitch mode that means snapshot#8 is always wrong. Anyone else seeing this bug?

 

Summary: I don't think the global settings for footswitch mode('Preset Mode Switches'),  and possibly the 'Snapshot Settings' as well, are interacting properly with block active/bypass state when doing preset design.  I think there is a bug where the 'Global Settings' --> Footswitches --> 'Preset Mode Switches' setting (Snapshots, Snap/Stomp, etc.) is interacting with how the active/bypass state is being saved in snapshots. The 'Preset Mode Switches' setting should not have any effect on a block's active/bypass state when saving presets or snapshots.

 

Also, although your Preferences --> 'Snapshot Edits' setting(Recall, Discard) setting can and should have an impact on how snapshots are saved as per design, there is a possibility this behavior may also be interacting in unexpected ways with block active/bypass states.  I have not run the above tests with 'Snapshot Settings' ="Recall" so I am not sure if results will vary depending on how this global setting interacts with the 'Preset Mode Switches' setting.

 

WORKAROUND: So, at least for right now the workaround if you want all your snapshots to inherit the bypass state of a newly added block is to set 'Global Settings' --> Footswitches --> 'Preset Mode Switches' = "Snaphots", at least for the duration of your preset design session. Make sure you are in snapshot#1 before you add your new block, bypass it, and save. Now go to snapshot #8 and bypass the block and save.

 

Bump, I know the post above is long but it really comes down to what are you seeing for the active/bypass state of the added block in the rest of your snapshots when you add a bypassed block to snapshot#1 and then save.  Is anyone else seeing the same bypass/active behavior described above? Trying to confirm if this is a bug or just happening on my Helix. Thanks!

[rzumwalt]

2 hours ago, HonestOpinion said:

When I do this in Snap/Stomp mode with for example four snapshots showing on my top row, stomps on the bottom row, the 4th thru 8th snapshots always seems to have the block state active, even if I set and saved it to be bypassed in snapshot#1. Snapshots #1 thru #3 have the block bypassed as I would expect. If I have the global preferences set to show all eight snapshots on the footswitches, then it improperly sets the bypassed block active only in snapshot #8. Kinda weird.

 

I may have noticed something similar to this, but I thought it was caused by something else. I don't know how many presets you tested your theory on, but it you might actually be seeing the baseline behavior of 'unedited" snapshots. So, this may or may not apply to what you are seeing.

My observation a while back seemed to be that every snapshot above the highest numbered snapshot you have actually gone into and made a change to acts like a mirror of the highest snapshot ("SS") you have changed. If you have only made changes to the first three SSs in a preset, then SSs 4-8 will always mirror SS 3, until you change one of them. If you make a change to SS 3, the change will be reflected in SSs 4-8 without you doing anything. If you then make a change to SS 4, then SSs 5-8 will always match SS 4, until you change one. Even if you open SSs 5-8, but don't change them, they stay in a "mirroring" state. I don't know that I was interpreting the behavior accurately, it was just my observation a few months ago while editing a couple presets, and I didn't rigorously test it out. I'm curious if anyone else can confirm whether that is the case. 

[HonestOpinion]

9 minutes ago, rzumwalt said:

 

I may have noticed something similar to this, but I thought it was caused by something else. I don't know how many presets you tested your theory on, but it you might actually be seeing the baseline behavior of 'unedited" snapshots. So, this may or may not apply to what you are seeing.

My observation a while back seemed to be that every snapshot above the highest numbered snapshot you have actually gone into and made a change to acts like a mirror of the highest snapshot ("SS") you have changed. If you have only made changes to the first three SSs in a preset, then SSs 4-8 will always mirror SS 3, until you change one of them. If you make a change to SS 3, the change will be reflected in SSs 4-8 without you doing anything. If you then make a change to SS 4, then SSs 5-8 will always match SS 4, until you change one. Even if you open SSs 5-8, but don't change them, they stay in a "mirroring" state. I don't know that I was interpreting the behavior accurately, it was just my observation a few months ago while editing a couple presets, and I didn't rigorously test it out. I'm curious if anyone else can confirm whether that is the case. 

 

Thanks for testing! I was running this test on new presets built from scratch. You definitely shed some additional light on the subject and I remember some similar observations of my own when snapshots were first released. I have not tested for this bug on presets that had already been built on this or former versions of the firmware/editor. Was just doing some quick tests to help test d0stennings observations. This definitely looks like a bug to me on new presets, will have to test further to see how older presets are behaving.

[silverhead]

From my limited testing re: the on/off state of new blocks and snapshots I see the same behaviour despite the age of the preset (new or old) and the number of customized snapshots. What I observe is independent of the mirroring of latter snapshots and independent of the saving of the preset or snapshot. 

 

What I observe is this: when you add a block to any preset it is by default, and immediately, in the On state in all snapshots in that preset. In other words, you cannot add a block in the bypassed state. It doesn't matter how many snapshots you have already customized. Doesn't matter how the mirroring of later snapshots behaves. Doesn't matter when you save the snapshot/preset or whether the Snapshot editing parameter is set to Discard or Recall. In all cases a preset contains 8 snapshots at all times and a newly added block appears in the On state in all 8 snapshots. From that point things behave as if the block had previously existed in the preset, in the On state in all snapshots. If you want to change the state in different snapshots you must bypass it manually and separately in individual snapshots, one snapshot st a time, saving them immediately or later depending on the Snapshot editing parameter setting.

[Doug6String]

Silverhead's experience is my experience, except, as I said above, if you copy a block that is "in the bypassed state" into a preset (from another preset), the default for it is off, eliminating the need to turn it off in every SS except for the SS the block is used in.

[HonestOpinion]

19 hours ago, silverhead said:

From my limited testing re: the on/off state of new blocks and snapshots I see the same behaviour despite the age of the preset (new or old) and the number of customized snapshots. What I observe is independent of the mirroring of latter snapshots and independent of the saving of the preset or snapshot. 

 

What I observe is this: when you add a block to any preset it is by default, and immediately, in the On state in all snapshots in that preset. In other words, you cannot add a block in the bypassed state. It doesn't matter how many snapshots you have already customized. Doesn't matter how the mirroring of later snapshots behaves. Doesn't matter when you save the snapshot/preset or whether the Snapshot editing parameter is set to Discard or Recall. In all cases a preset contains 8 snapshots at all times and a newly added block appears in the On state in all 8 snapshots. From that point things behave as if the block had previously existed in the preset, in the On state in all snapshots. If you want to change the state in different snapshots you must bypass it manually and separately in individual snapshots, one snapshot st a time, saving them immediately or later depending on the Snapshot editing parameter setting.

 

Strange, I am able to add new blocks in and have them show up as bypassed in every snapshot with the exception of snapshot#8. I repeated my tests and I am still getting essentially the same results.

The global settings are:

1. Footswitches --> 'Preset Mode Switches'  = "8 Snapshots" 
2. Footswitches --> 'Stomp Mode Switches' = "10 Switches"
3. Preferences --> 'Snapshot Edits' = "Discard"

I add a block in snapshot#1, bypass it, save the preset and all the snapshots are saved as bypassed with the exception of snapshot#8.

 

Now here is where it gets weird. If I select snapshot#8 (which is the only snapshot that did not bypass the block, it is active) now any other snapshot I select has the block active. Even through they weren't before I selected snapshot#8. If I go back to snapshot#1 the block is bypassed and now any other snapshot I select, as long as I don't pick snapshot#8 is bypassed again. This is with 'Snapshots Edit' = "Discard". Unless my firmware requires re-flashing or a global reset this has got to be a bug.

[silverhead]

I would reinstall the firmware and see if you can reproduce this. Sounds like a firmware corruption to me. But if it's reproducible please report it.

[duncann]

14 hours ago, HonestOpinion said:

 

Strange, I am able to add new blocks in and have them show up as bypassed in every snapshot with the exception of snapshot#8. I repeated my tests and I am still getting essentially the same results.

The global settings are:

1. Footswitches --> 'Preset Mode Switches'  = "8 Snapshots" 
2. Footswitches --> 'Stomp Mode Switches' = "10 Switches"
3. Preferences --> 'Snapshot Edits' = "Discard"

I add a block in snapshot#1, bypass it, save the preset and all the snapshots are saved as bypassed with the exception of snapshot#8.

 

Now here is where it gets weird. If I select snapshot#8 (which is the only snapshot that did not bypass the block, it is active) now any other snapshot I select has the block active. Even through they weren't before I selected snapshot#8. If I go back to snapshot#1 the block is bypassed and now any other snapshot I select, as long as I don't pick snapshot#8 is bypassed again. This is with 'Snapshots Edit' = "Discard". Unless my firmware requires re-flashing or a global reset this has got to be a bug.

 

I can't get exactly this behavior, but I can get some unexpected results with the same global settings and adding a block (deluxe comp mono) in snapshot1, bypassing it, saving the preset.

Then cycling through all the snapshots, everything seems good. Then to uncover the weird behavior.

 

1. Engage another snapshot, say #4, and enable the block.

2. Cycle to 5, 6, 7, then 8, and the block is enabled in all of them.

3. Cycle back down, from 8 to 7, 6, 5, 4, 3, then 2. Still enabled in all.

4. Go to snapshot1. The block is disabled.

5. Cycle back up to 8. All snapshots have the block disabled.

6. Engage another snapshot, say #5, and enable the block.

7. Cycle down to 4, then 3, 2. The block is enabled in all of them.

8. Cycle down to snapshot1. The block is disabled.

 

Doesn't seem right. And when the global is set to recall, it has different behavior, but also weird.

[HonestOpinion]

5 hours ago, duncann said:

 

I can't get exactly this behavior, but I can get some unexpected results with the same global settings and adding a block (deluxe comp mono) in snapshot1, bypassing it, saving the preset.

Then cycling through all the snapshots, everything seems good. Then to uncover the weird behavior.

 

1. Engage another snapshot, say #4, and enable the block.

2. Cycle to 5, 6, 7, then 8, and the block is enabled in all of them.

3. Cycle back down, from 8 to 7, 6, 5, 4, 3, then 2. Still enabled in all.

4. Go to snapshot1. The block is disabled.

5. Cycle back up to 8. All snapshots have the block disabled.

6. Engage another snapshot, say #5, and enable the block.

7. Cycle down to 4, then 3, 2. The block is enabled in all of them.

8. Cycle down to snapshot1. The block is disabled.

 

Doesn't seem right. And when the global is set to recall, it has different behavior, but also weird.

 

Thanks for testing! It would be interesting to see some other folks' results. Something just doesn't seem right with the snapshot bypass/active block state saving and there may be more global settings or variables involved than the ones I listed which may explain why different users are experiencing different results. Can't say for sure yet until more people run tests but my gut feeling is there is a bug here.

[HonestOpinion]

Would really help to get a few more folks testing  this bug. If confirmed I think it should probably opened up as a help ticket with Line6.