Timer CHOP done_pulse issues

So in a project I’m working on I have a few things that need to be triggered t amount of time after another event. I’m trying to use the done_pulse output for the timer chop to achieve this but the pulse seems to work correctly maybe 1 in 30 times. This seems like a pretty major issue for something that I imagine is pretty universally needed.

I’m trying the timer in terms of seconds, frames and samples. If I open up the callbacks DAT and add
def onDone(timerOp, segment, interrupt):
op(‘timer’)[‘done_pulse’]=1
return
it increases the success rate to about 50/50, still not very useful. My project is running at
fps by the way.
If anyone has any answers on how to accomplish this without a paragraph of code for every time I need this function or can figure out what’s going wrong here, it would be much appreciated.

As you didn’t post your patch I can’t see what you’ve built, but I’m guessing your code is looking for the pulse just before or after the pulse fires, that’s why I usually use the ‘done’ channel to trigger other events, as that one stays up, so it’s far easier to check&debug in your code.

You can check the done_pulse actually fired with a a Trail Chop. You’ll see many examples of this in Help - > Opsnippets → Timer CHOP.

But it’s much easier easier to help you and discuss your code if you post a (small) network of what you have build so far with the Timer CHOP in trying to trigger something.

Ok, that’s bizarre, there’s no feedback of it working from timer’s display but I can see on the trail that it is. The cache of the image I’m triggering is compiled into the final display so it just needed more than a single frame to work. I was able to trigger a second timer with timer done and use that to give me a bigger window. Thanks for the quick feedback!

yes, a pulse is easy to miss, and in your case you don’t want a pulse.

More notes on your use of the Timer CHOP:

Regarding:
def onDone(timerOp, segment, interrupt):
op(‘timer’)[‘done_pulse’]=1
return

In general with CHOPs, you shouldn’t be forcing anything into the output channels of any CHOP by setting its values… They are read-only and fully-generated by the operator itself. In hindsight, we should flag this as an error or warning on the operator so that you know this isn’t permitted. Our apologies.

“done_pulse” is on for at least one frame always, as I think you will see with the Trail CHOP. (It will be 2 or more frames if you are dropping frames.)

It’s OK if you use the “done” channel too if you are just looking for a channel to go off-to-on at the end.

A second timer is suitable to use, sending the done or done_pulse channel to the start input of the second CHOP.

Or as you can see with the OP Snippets for the Timer CHOP, there are other ways, like using segments (which is like several timers in one, one after the other, or running at the same time).

As nettoyeur comments, I’d like to know more about how you were doing it initially where you were missing events. Can you post a sample network?

I’m actually also having this issue. The Timer_Done Pulses seem to be inconsistent at triggering the next batch of timers. I’m probably going to go down a different route instead of stacking these timers, but this is how I’ve got them arranged. The cues are built on the output of logic CHOPs that look for a LTC timecode bound - I usually set them for about 4-5 frames. The input then triggers the associated cues that have a delay, fade up, cue time, and fade down. This way the cue emulates a lighting console. In my current test that uses about 10 cues about 3-4 of them don’t trigger. However, which cues don’t work at any given time change each time I run it. I’m attaching the “buggy” version here. I don’t need an answer as I’m going to rewrite how I trigger anyway, but maybe you can provide insight into it. I only noticed it when I started running multiple cues.

Jeff
CueTrigger.toe (5.67 KB)