Delay chop bugged (again)

I report a BUG of the DELAY CHOP operator.
I attach an example file with a comparison of the same operation performed by the LAG and TIMER operators.

The operation is simple, there are 3 DELAY operators:

  • the first must read cell 1 and write it on 2
  • the second must read cell 0 and write it to cell 1
  • the third must read cell 2 and write it on cell 0

Each Delay is 0.1 second ahead of the one before it.
I perform the same operation with the LAG and TIMER operators.

By letting the code run, at a certain point the DELAY operators will generate the BUG (the 3 cells will contain the same value) while the other operators (LAG and TIMER) will continue to work without problems.

In the attached example you will find various situations, with independent or concatenated DELAY and LAG operators.

To speed up the generation of the bug, repeatedly press Perform and press the ESC key a few times to stimulate TD with the workload.

TD versions on which the bug is found:


DelayChopBUG - 2022.35320 .toe (7.6 KB)

Hi @labicone,

this is more the effect of Time Slicing than an actual bug. You can reproduce the behavior nicely when adding a Hog CHOP and setting the Hog’s “Delay” parameter to 1/me.time.rate (or 1 frame when changing the unit menu) To monitor the behaviour and see the CHOP Executes trigger more often or less often then expected, add a print statement to each referencing their name, something like:


For the first CHOP Execute additionally do:


and you will be able to tell apart the sequences nicely.

With time slicing the data from a skipped frame is not lost but maintained and processed - just a frame later - the Delay CHOPs then hold 2 or more samples worth of data and each sample now comes with their own delay. I will check though as I’m not sure it retains the correct time slice. Looks a bit strange.
Still, it’d be difficult to rely on the Delay CHOP for that reason to trigger scripts.
Append a Trail CHOP to all 3 to see how they execute, sometimes twice in a row or miss pulses.

The Lag on the other hand will always work in the way you have it set up, it’s not that the Lag time has anything to do with it, but the order that they are connected. Or, in case of the second with individual branches of Lags, the order the CHOP Executes are created. Reason here is that the CHOP Execute’s onOffToOn triggers as soon as the referenced value is >0 which even with a lag happens right away, it just takes a bit longer to reach the final value.

The Timer CHOP runs really solid on these tasks.