Delay/Verb Trails and Snapshots

[gunpointmetal]

So, when I switch snapshots from a sound with trails on delay/reverb to a snapshot with those effects bypassed, I'm getting weird glitches in the trails because it would seem the effect is changing its parameters to whatever they are in the next snapshot, even though they are bypassed. Is this something that can be repaired in future firmware so that the parameters don't change if the effect is in an OFF state when snapshots are changed?

[zooey]

Good idea!

 

EDIT: (unintentionally posted before finishing):

Except what happens if you then turn it on with a footswitch? It has to have the new parameters by then.

[gunpointmetal]

I agree, and see where that is an issue, maybe the parameters don't change until an effect is activated again?

[njglover]

I'm not sure that it will be possible. Trails work by allowing the effect to continue for a time even after it has been switched off. If the parameters change on the effect, then of course you are going to hear it because the effect is still active. You could potentially program it so that if trails is set to on and the next change is bypass that it waits until after it is fully off before switching parameters, but I'm not sure if trails are a fixed length or determined by the delay settings, so this might not be feasible.

[jbuhajla]

If you are changing the time base or tempo of a delay with snapshots then you'll get that effect just the same as reaching down and turning the "time" value on the delay while playing. To minimize that effect, go to Global Settings>Preferences>Tap Tempo Pitch and select "transparent". 

 

It may still sound a little glitchy if you make a big change in tempo or time base, but I have found that I can live with it. It's either that or turn trails off for that particular preset. 

[jbuhajla]

...another thought. Even though you are going to a snapshot with the effect bypassed, the tempo or time base may be different. Make the tempo match on the effect in both snapshots. The effect is still trailing when you activate the other snapshot, so the tempo/time base will still effect the trails. 

[zooey]

You can't do that in all cases, or you couldn't have different delay times for different snaps.

 

Seems to me you'd have to set this up manually yourself, by matching the delay times in the snaps where that was an issue. If you set them in musical units controlled by that patch temp, you can change the delay time with the temp stomp switch, but all snapshots will change together.

[jbuhajla]

You can't do that in all cases, or you couldn't have different delay times for different snaps.

 

True, but in his case where going to a snap with the delay bypassed, setting identical tempo/time base should do the trick. 

 

In some cases where I change delay tempo with snaps, I just have to do it in a place in the song where I can live with the faint glitchy sound. Sometimes it sounds pretty cool so I don't even worry about it. It's a small price to pay for having the extreme flexibility of snapshots. 

[gunpointmetal]

Just another reason I wish Preset switching was at a reasonable speed. I guess I'll end up turning trails off for most of my snapshots, since the glitches are super annoying when all I want is my last clean cord to ring out underneath the riff when I switch to a dirt channel. Still better than tap dancing all over an analog board, I guess.

[jbuhajla]

You could also run your delay in parallel with a y-split, then turn off the signal to the delay on the next snapshot. The delay would still be active and trailing, but your signal no longer going to the delay input. I'm sure there is a way to make it work with some creativity. Another great thing about the Helix: you no longer have to think within the box of typical effect routing. 

[zooey]

Same issue about when delay time should switch would apply to changing presets. You definitely need to be able to have different delay times per preset!

[gunpointmetal]

As I'm implementing it, I have Snapshots set up as my "patches" on a pedal board, so I have 3 clean snapshots with varying degrees/settings of delay/reverb, a "dry" heavy patch, and a couple of "crunch" patches with effects, but everything is using the same 2-3 time-based effects, so even if I set up one snapshot change from clean-drive with the delay/verb settings the same, that won't work coming from a different snapshot back to the drive patch with no effects. I'm sure it would be convoluted to have the delay/verb tails unaffected by by a settings change.

[njglover]

Just another reason I wish Preset switching was at a reasonable speed. I guess I'll end up turning trails off for most of my snapshots, since the glitches are super annoying when all I want is my last clean cord to ring out underneath the riff when I switch to a dirt channel. Still better than tap dancing all over an analog board, I guess.

 

That wouldn't work at all, you can't have trails from one preset to another and if you did it wouldn't be any different. You can solve the problem by just using a different delay, though that will use more DSP. It's just the way it is. If you want to change the tempo of the delay, it's going to sound like you are changing the tempo.

[HonestOpinion]

I wonder if you would still get trails but not the glitch if you assign the 'Mix' parameter to snapshots ('Trails' activated) and simply leave the delay/reverb activated when you switch snapshots but change the 'Mix' to 0% so that it is not affecting your snapshot, instead of bypassing the block.

[jbuhajla]

I wonder if you would still get trails but not the glitch if you assign the 'Mix' parameter to snapshots ('Trails' activated) and simply leave the delay/reverb activated when you switch snapshots but change the 'Mix' to 0% instead of bypassing it so that it is not effecting your preset.

I will definitely try that. 

[zooey]

If I'm understanding correctly, the problem being reported isn't from changing from active to bypassed. It's that the delay time in the second snap is different, and it affects trails even though it's now bypassed.

 

Unfortunately, that means that using the mix parameter to mute the effect, instead of actual bypass, wouldn't make any difference, the delay time still changes.

 

The workaround/fix is to keep delay times the same across snapshots you navigate between frequently when you have trails turned on.

 

Or embrace the glitches, call them cool, watch people stress trying to duplicate the effect!

[gunpointmetal]

It'd be kinda lame to have the exact same delay setting on everything using delay throughout a set. I guess I could change them to beat values and use the tap tempo, but I kinda set them up the way they are for specific things. It does occasionally produce "cool" artifacts, but I would like to have some real control over it.

[HonestOpinion]

If I'm understanding correctly, the problem being reported isn't from changing from active to bypassed. It's that the delay time in the second snap is different, and it affects trails even though it's now bypassed.

 

Unfortunately, that means that using the mix parameter to mute the effect, instead of actual bypass, wouldn't make any difference, the delay time still changes.

 

The workaround/fix is to keep delay times the same across snapshots you navigate between frequently when you have trails turned on.

 

Or embrace the glitches, call them cool, watch people stress trying to duplicate the effect!

 

Hmm, upon closer examination of the OP's original post and experimenting with it myself you are absolutely correct. I guess another way to address this then (if you have the DSP available) is to set up a second delay/reverb for the alternate settings; this works as I tried it, although only if the second delay/reverb block is bypassed in the second snapshot when you switch. The first matching delay/reverbs block keep the trails consistent between snapshots and the second is for your alternate settings. 

 

 I think I may have noticed a second bug/feature here with trails. The trails from a snapshot are not only being affected if there are different parameters on another snapshot but actually being reprocessed by other blocks. I put a second delay block after the first one I was using to run experiments with trails. If I switch snapshots and the second delay is activated (it was bypassed in the first snapstho) It appears to be processing the trails from the first snapshot and adding a delay to them.  My understanding of trails is that they should not be processed by the blocks from a subsequent snapshot. They are simply the trailing remainder of the last snapshot. I am hoping someone else can confirm this. It appears if I add a second delay block to the second snapshot so that the 1st delay block=active and the 2nd delay block=bypassed in the first snapshot. My second snapshot has the 1st delay block=bypassed and the 2nd delay block=active. They both have 'Trails' activated. Perhaps I am getting confused but it appears that when you switch from the first snapshot, to the second one, the trails from the first snapshot are actually getting delayed again by the second delay block on the second snapshot. To test this I set the two delay blocks up with different delay 'Time's and set the 'Feedback' and 'Mix' levels up high to make sure I could hear them.

 

This behavior becomes really obvious if you put a distortion block after the delay block. Bypass it on the first snapshot and activate it on the second snapshot. Make the first snapshot a clean sound with a long delay and high feedback and mix level so you can easily hear the repeats several times (make sure trails are on).  When you switch to the second block your trails are now distorted. I would expect the trails from the clean first snapshot to remain clean and not be processed as distorted by the distortion block that is now on. I suppose this is not a problem as long as you don't have any blocks that become active after a snapshot change that are after your trailed delay/reverb in the signal chain. Is this the same behavior other people are hearing?

 

Ideally it seems the behavior would be that the trails to finish being processed only by the parameters from the first snapshot regardless of the parameters for the second. In essence the trails from the first snapshot need to be in memory as a separate entity that can complete independently of whatever is being switched to and played in the subsequent snapshot. Almost as if the trails were in a looper (played once without being looped) at the end of a signal chain, unaffected by what comes before them in the signal chain of the second snapshot.

 

If people need a choice as to how trails work perhaps an additional global or per preset setting for the trails behavior might be another option. The question is whether the Helix can be given the capacity to allow the trails' delayed signal to complete without changing from one snapshot to another regardless of which blocks are activated or which set of parameters changes, while simultaneously allowing the blocks activated and new parameters to take over anything played after the snapshot switch. Such that for example the last delay from your clean rhythm is trailing as you kick in your lead. Or such that my trailing delay does not audibly glitch or have its settings modified or reprocessed and delayed again by switching to a subsequent snapshot. The same thing applies when I switch back from a lead snapshot to a clean rhythm snapshot. I don't want my last trailing lead delay (played in my lead snapshot) to all of a sudden become clean instead of distorted because the distortion block is not activated in my clean snapshot. That is my most typical scenario for how I would like my trails to operate. 

 

IMHO this is genuine problem or at least a lack of flexibility with how trails have been implemented and I hope it gets addressed at some point.

[gunpointmetal]

Thats pretty much exactly what I was hoping or expecting it to do. I've never used and analog or digital single pedal with trails, but I would assume that if you de-activated the effect and there were still repeats going, adjusting knobs on the pedal after its off wouldn't effect the trails? 

 

It would be handy to have a way to do this, because it kinda defeats the purpose of having the tails on in most of my snapshots if when I switch I'm going to get a weird pitch shift/glitch sound where what I want is the hanging delay to echo out underneath whatever the next tone I select would be. 

[zooey]

PROBLEM SCENARIO

1. Snapshot A has a 500ms delay with trails on, and in B it's 300ms, but the delay is off

2. You're playing along in A and switch to B

 

DILEMMA

- If the delay time changes to 300ms, as it does now, you hear glitches

- If it doesn't change, it's not at the setting stored in the snapshot when you turn it on, clearly wrong and unhelpful

 

POTENTIAL SOLUTION

- If the previous snapshot had a delay on with trails enabled

    AND

- If that same delay is off in the current snapshot

    AND

- If that same delay has a different time setting than the previous snapshot

   THEN

- Don't change the delay time to what's in the current snapshot until something (stomp switch or snapshot change) turns that delay on

 

That'd be better in most cases, but still not bulletproof, potentially still wrong if you then quickly went to another snapshot, muddying the idea of "the previous snapshot".

 

It also seems like a lot of work and testing and potential bugs for an inherently transient case that may not be all that commonly a problem.

[HonestOpinion]

PROBLEM SCENARIO

1. Snapshot A has a 500ms delay with trails on, and in B it's 300ms, but the delay is off

2. You're playing along in A and switch to B

 

DILEMMA

- If the delay time changes to 300ms, as it does now, you hear glitches

- If it doesn't change, it's not at the setting stored in the snapshot when you turn it on, clearly wrong and unhelpful

 

POTENTIAL SOLUTION

- If the previous snapshot had a delay on with trails enabled

    AND

- If that same delay is off in the current snapshot

    AND

- If that same delay has a different time setting than the previous snapshot

   THEN

- Don't change the delay time to what's in the current snapshot until something (stomp switch or snapshot change) turns that delay on

 

...

 

Nice elegant solution! That would take care of many problem scenarios as long as you do not have effect blocks coming on that are after the trailed delay/reverb blocks in a subsequent snapshot. It also does not solve the problem of going to a snapshot where trails are on but the parameters change on the delay/reverb block and the delay/reverb block is activated in both snapshots.

[EdwinV]

  I think I may have noticed a second bug/feature here with trails. The trails from a snapshot are not only being affected if there are different parameters on another snapshot but actually being reprocessed by other blocks. I put a second delay block after the first one I was using to run experiments with trails. If I switch snapshots and the second delay is activated (it was bypassed in the first snapstho) It appears to be processing the trails from the first snapshot and adding a delay to them.  My understanding of trails is that they should not be processed by the blocks from a subsequent snapshot. They are simply the trailing remainder of the last snapshot. I am hoping someone else can confirm this.

 

[.....]

 

IMHO this is genuine problem or at least a lack of flexibility with how trails have been implemented and I hope it gets addressed at some point.

Sorry, but is the Helix not just doing what it's supposed to do? With a normal pedalboard, the behavior would be exactly the same. The trails are feeding into everything downstream and whatever you turn on there will affect (effect 😉) your signal.

 

If you don't want that, you may try splitting the last part of your signal chain (into A and B path, one delay in A and the other in B ).

 

Maybe I'm silly, but I wouldn't want this to be "fixed" ...

 

Cheers!

[HonestOpinion]

Sorry, but is the Helix not just doing what it's supposed to do? With a normal pedalboard, the behavior would be exactly the same. The trails are feeding into everything downstream and whatever you turn on there will affect (effect ) your signal.

 

If you don't want that, you may try splitting the last part of your signal chain (into A and B path, one delay in A and the other in B ).

 

Maybe I'm silly, but I wouldn't want this to be "fixed" ...

 

Cheers!

 

Regarding what happens when you put an effect block after a delay/reverb block I understand your reasoning. Not silly at all, the same thought occurred to me ("the operation being similar to an analog pedalboard") at least as it regards putting effects after a pedal with trails. However it also occurred to me that we are in the digital realm and people around here justifiably and fairly regularly point out that all the rules don't need to be the same. We can make improvements on limitations imposed by analog rigs. I would agree though that not putting any blocks after your delay/reverb blocks with trails or alternate routing is the easiest way to address that issue without having to enhance the trails functionality.

 

The glitch between snapshots however is not analogous to analog pedalboard behavior. This is the issue that I would be more keen to see addressed in such a way that having different settings on the delay/reverb blocks in a subsequent snapshot does not cause a glitch in the trails from the prior snapshot, whether the delay/reverb block is bypassed or active in the subsequent snapshot.

 

Note: I ordinarily do not put effect blocks after the delay/reverb blocks. The only reason I noticed the reprocessing 'feature' on trails is because I was forced to experiment with a second delay block placed after the first in an effort to prevent the glitch in the trails caused by switching snapshots.

[zooey]

Nice elegant solution! That would take care of many problem scenarios as long as you do not have effect blocks coming on that are after the trailed delay/reverb blocks in a subsequent snapshot. It also does not solve the problem of going to a snapshot where trails are on but the parameters change on the delay/reverb block and the delay/reverb block is activated in both snapshots.

Well if it's active in the second snap, it HAS to change to the time stored in that snap, right? If you're looking for the previous snap's trails to use the old time (and other settings), but the second snap's new-signal processing to use the settings from that snapshot, they overlap, and that inherently means two delays. You could build that yourself with two delays, but a single delay block has a single delay time in effect at a time.

[HonestOpinion]

Well if it's active in the second snap, it HAS to change to the time stored in that snap, right? If you're looking for the previous snap's trails to use the old time (and other settings), but the second snap's new-signal processing to use the settings from that snapshot, they overlap, and that inherently means two delays. You could build that yourself with two delays, but a single delay block has a single delay time in effect at a time.

 

We definitely start with the basic premise you laid out earlier that switching to a new snapshot has to immediately make the new delay settings available if the block is already active or alternatively when the block is activated. The desired objective would be to enable the use of both trails and parameter changes on the same block without glitching between snapshot changes.

 

Perhaps in the digital domain, when switching to another snapshot with the same delay block activated, momentarily, and for the duration of the trails completing, there are in essence two delay blocks active. One with the old settings processing the trails from the final note/chord before the snapshot switch and then the delay block with the new settings kicking in as those final trail bits are processed. Even if this means that in programming terms there has to be two versions of the same delay block active for a moment in time that does not necessarily translate to a user having to gin up two separate delay blocks. That processing can be done behind the scenes for the user.

 

If it requires two actual copies of the same delay block the DSP would have to be allotted ahead of time when trails are first set on for a block. We know that from recent discussions on other topics regarding how all blocks within a preset, active or not, are loaded into the DSP as soon as a preset is selected. It would seem that there was some magic in the way Line6 programmed trails that did not double the DSP requirements when trails are turned on. I have never had a preset give me an out of DSP message due to turning on the trails feature. I am assuming they trails are coded in such a way, optimized, swapped out to memory, whatever. such that the DSP cost did not double. Perhaps that 'magic' is simply not possible if you also change the parameters while using trails. The block may need all/certain parameters to remain absolutely unchanged from snapshot to snapshot to function properly. This makes the snapshot operation of blocks with trails different from all other blocks, above and beyond their ability to provide trails. Perhaps Line6 will figure a way to make trails work properly with parameter changes on the same block but for now that does not appear to be the case. Even if they do it may come at the cost of additional DSP (in essence a second virtual block copy).

 

So in summation... I was sort of under the impression that the whole intention of trails functionality in addition to the obvious sound benefit was to perform the trails functionality transparently for the user without the need for an additional copy of the delay/reverb block created by the user. The ability to assign parameters to snapshots seemed to be an elegant way to change them between snapshots instead of creating and switching to another copy of the same effect block and the attendant additional cost in DSP. Perhaps however enabling trails and also changing parameters is not possible without pre-instantiating two copies of a block. The second 'copy' block could be instantiated automatically behind the scenes by the Helix when trails are set on but only when a parameter change option is explicitly set by the user. If a second virtual block copy is ultimately what is required then I can see adding an additional parameter like 'Enable Parameter Switching' for use when the user want to change parameter settings between snapshots on blocks with trails. That way the firmware is not wasting the DSP on an internal second copy of a block with trails when its parameters are not being changed between snapshots. The second copy would not be required in that scenario. I was hoping that there might be a better alternative than a 'two block solution' to get both trails and parameter changes to operate on one block simultaneously but perhaps there is not.

[gunpointmetal]

Seems like I'll just be turning trails off for the time being. 

[zooey]

Trails inherently make any block using them behave differently from ones without trails.

 

As for having Helix automatically create a second delay instance to handle that case, maybe. Besides the work to build it, I've already said I'd rather have all DSP requirements be predetermined, so you know when you build a patch that you you can use any combination of the blocks in it, instead of running into DSP limits while you're playing. In order to do that, Helix would have reserve DSP for a second delay block in any patch that had one, in case this scenario comes up. Personally, I'd rather leave that juggling in the hands of players for this is an issue, when it is.

[HonestOpinion]

Trails inherently make any block using them behave differently from ones without trails.

 

As for having Helix automatically create a second delay instance to handle that case, maybe. Besides the work to build it, I've already said I'd rather have all DSP requirements be predetermined, so you know when you build a patch that you you can use any combination of the blocks in it, instead of running into DSP limits while you're playing. In order to do that, Helix would have reserve DSP for a second delay block in any patch that had one, in case this scenario comes up. Personally, I'd rather leave that juggling in the hands of players for this is an issue, when it is.

 

Agreed, the discussion regarding DSP preallocation was resolved by DI in that other topic you are referring to. If the second block is required the DSP definitely has to be allocated beforehand when the trails/parameters option is selected, whether the Helix creates a second copy of a block automatically behind the scenes or the user does it explicitly. Ultimately I just don't want to make too many assumptions about what is required to make this work. Just want to lay out what the ideal scenario would be and let Line6 hopefully take it from there. Ideal scenario is trails and parameter changes work on the same block. Minimum of fuss and user intervention that way.

[HonestOpinion]

Seems like I'll just be turning trails off for the time being. 

 

Without creating a second delay/reverb block, I think right now that is the only alternative that makes sense if you are switching the parameters for the delay/reverb between snapshots. If you are not then you have the option of leaving trails on. I look forward to Line6 giving us the option to both have trails on and also switch parameters without glitching. Thanks for catching this issue!

[duncann]

As a possible workaround, if you have a parallel path available for the delay/reverb, always leave the delay/reverb turned on, and don't worry about the trails parameter. If you want them turned off, change the A/B path split instead to enable/disable the reverb/delay. Or something along these lines. Or maybe this scheme would produce the same glitches your hearing. I haven't tried it.

[gunpointmetal]

As a possible workaround, if you have a parallel path available for the delay/reverb, always leave the delay/reverb turned on, and don't worry about the trails parameter. If you want them turned off, change the A/B path split instead to enable/disable the reverb/delay. Or something along these lines. Or maybe this scheme would produce the same glitches your hearing. I haven't tried it.

I think I'm going to get the glitches unless the settings on the verbs and delays stay the same from snapshot to snapshot. 

[duncann]

I think I'm going to get the glitches unless the settings on the verbs and delays stay the same from snapshot to snapshot. 

 

Yep, you're right, it still does glitch.

[zooey]

Would you be happier controlling delay time with a switch or exp pedal than having it change with snapshots? You could change it at a moment that you knew wouldn't glitch. OTOH, you would have to do that.

 

I wouldn't rule out separate delays in each snap either. Sounds extravagant maybe, but I don't think they use tons of DSP.

 

One of those options seems like the way to go given the current tech.

[gunpointmetal]

The thing is, the way I have these Snapshots set-up (this is for a live patch), I'd need 4-5 delays to have different settings on all the "cleanish" tones that use delay, and I'm already using a pretty loaded "board" for this patch. 

[miguelafranco]

hello people I communicate from uruguay. Sorry if I write badly since I speak Spanish and I'm translating with google. I comment that in settings - global settings - tap tempo pitch. It must be set to transparent, so changing the tempo from one sanpshot to another does not change the pitch of the delay tails. greetings to everyone to enjoy this piece of machine