Hi i think that a DELAY patch could be extremely usefull: delay any message given a time value. This would prevent excessive use of the Queue patch, esp. that you can't really control precisely how long the delay will be. Maybe someone already has a macro for this ?

cwright's picture

I don't think there's a good way that a macro could handle this -- you'd need 2 queues (one to record messages, and one to record time stamps), and then you'd need to walk over both structures to find out which message you need to output. Depending on the length of the delay, this could get really expensive (on both memory and cpu).

While the memory expense can't really be helped (storing a thousand images is going to use lots of memory, no matter what), a custom patch to handle this could operate pretty quickly (binary search) to output proper values.

So you're thinking it would have an object input and output, and a number input that controls how long to delay?

What happens when you have the delay set to something really short (0.1 sec), run it for a while, and then change it to something really big (100sec) -- should it keep around objects forever so you can increase the delay to anything? That's not going to be stable...

franz's picture

Yes, i was thinking: - 2 inputs: data input and delay (number in seconds) - 1 output: delayed data. Rising the delay time would keep more objects, while lowering delay time would just trash unnecessary data.

This is absolutely not about storing images, as a Queue patch seems more appropriate for this task. Just a simple delay for numbers or strings or bools. With maybe a time limit to prevent excessive memory usage.

I'm actually using the stopwatch trick mentioned by psonice, but you end up with tons of annoying stopwatches everywhere, plus conditionals.... and i really don't like the idea of hand-timing everything for such a simple task. Sometimes simple things in QC tend to become overly complicated. This is exactly why i would request a "clean" delay patch

psonice's picture

I've used a 'delay' system quite a few times. I've not got it as a macro though, I should do that as it's handy. The way I did it (from memory, so possibly inaccurate):

Use a 'sample and hold' to store the value, with a pulse on the sampling input so it just samples once. The output of the pulse should also trigger a stopwatch, so it starts counting - this handles the actual delay. You then need a conditional that tests if the time passed is greater than the delay time. Something like a math expression patch with "time>delay" does it. Time is taken from the stopwatch, delay is published as your delay parameter. The conditional needs to do two things when it's triggered: stop the stopwatch (and reset it to 0) and 'release' the delayed output. Depending on exactly how you want it to work, you can either: - use a multiplexer. One input contains a 'default' value (e.g. it's 0 if it's a number you're delaying), the other is connected to the output of the sample and hold. The conditional switches to the sampled input once the delay is passed. - use another sample and hold. The conditional triggers the sampling input so that after a delay the new value is passed, then held until a new delay is triggered and completed.

Hope that makes some sense?

cwright's picture
good solution

stopwatch is a clever way to handle this, good idea.

The only drawback (and this depends upon usage) is that you can't record any values while delaying, so it's actually ignoring everything in between samples.. not quite a true delay, in the audio delay sense (where all samples are offset in time by a specified amount).

psonice's picture
queueless delay

You're right - I was thinking of 'delaying a value' rather than 'passing through a delayed stream'.

For the 'delayed stream of data' case, a queue is the obvious candidate - the delay is 'easy' to adjust: you just multiply the required delay by the FPS to get the right queue length. What isn't quite so 'easy' though is if the fps varies ;) Still, it'd be fine for simple/fast compositions, and it'd be fine for capture.

For a more 'practical' version, I guess you could do it fairly easily with javascript. You'd replicate the queue functionality with an array, and add a timestamp, then cut members of the array out and pass the values out when their time comes. Not too difficult really, and it should be fast enough if the delay is not too long.

But yes, either way there are some serious issues - for simple values and shortish delays, it would be fine, but for large images with a long delay it'd kill the mac pretty fast ;)

Changes in the delay time would be fairly nasty too, you'd get either still frames, empty output, or sudden cuts. There's a way around it though - smooth the delay input. That way you could ensure that changes in delay are slow enough for the queue to adjust without leaving gaps.'s picture

If you are thinking of building this Chris, can I just say that every good delay box needs gain and feedback dials!

The rest can handled outside via delay time input (modulation etc). Suppose feedback can too for that matter but for ease of use...