Delay node

Input any data type, output data delayed by n seconds.

I could go for a node that did this.

I think that this and other FQ could be easily solved whenever “Publish Generic Ports” FQ is. So, I’d give priority to this latter.

You kind of have it in the enqueue node, but it will be delayed by frames instead of seconds. If you need precise timing, using a Fire Periodically node for the control data could be an option.

To get a 1 second delay using an enqueue node and with a refresh rate of 30 events per second,you just get item 31 from the resulting list from the *Enqueue *node.

If you want a 1 second delay from audio, I don’t think this is the correct approach though, as you’d have to get item 48001 for a 1 second delay at the default sample rate. Maybe there are some data nodes that would be better suited, or just recording and playing back from the same file (tape delay) would be the best way to solve it., maybe delay is the wrong word for what I was thinking. Maybe latency is a better word. Delay I think would be waiting a set amount of time and the allowing the data to passthrough in real-time, latency would be caching the real-time data stream for a specified period of time and then beginning to play the cached data back at an offset timeframe from the real-time data stream.

I don’t think the enqueue node can be used this way, or maybe I’m about to learn something. ;)  

That’s what the enqueue node effectively does ;) It stores any incoming value as the first item in the list, and copies the previous value to the next position in the list. So at 30 events per second, the 31st item will always be one second behind the original data stream. At 50 events per second, the 51st item will be one second behind and so on.

An easy way to see if it checks out is to connect your webcam (live video input) to an enqueue node and the background input of a blend image node. Then with a get item from list set to item 31 (if you’re at 30 fps) pipe it from the enqueue node to the foreground and render to window. Holding up a phone with a running timer on it should now display as one second behind in the foreground image.

Oh ya, you’re right. I haven’t used it in a while, I wasn’t using it for images. I’ll have to play with it some more to refresh my memory.

@MartinusMagneson This assumes you don’t mind having your events time-quantised. Conceptually, I think @Chris is looking for something where the timecode of the event coming in is considered, when it comes out the other end of the pipe.

I tried Enqueue for audio, didn’t seem to work so well?  

@keithlang True! But then again, you are de facto quantized in any digital application. I might have a strict definition of what a delay is (repetition of a previous event), but you can’t delay anything that didn’t exist in the first place at a place it isn’t played back.

This means that if you in any application at a 30 Hz refresh rate delay something at for instance 0.95 seconds, it will visually play back after either 0.93 or 0.96 seconds.

From a UX perspective, a frame-independent presentation of a delay would certainly be neater, but I think you can still visually achieve the same results.

If the hypothetical action at 0.95 seconds were really really important to get right, there is also an option to subtract your delay from the source time for a duplicate node of what creates the control data. As far as I know, noise nodes in the same composition are for instance not random from each other, but will produce the same results given the same time/position input. This means you can visually achieve a delay-like effect with data that isn’t present in the original flow.

@jersmi yup, I think the enqueue node will enqueue channels of 512 samples each if i remember it right. I’m not sure if there exists a good solution for delaying audio yet either. I think the “easiest” approach would be to write the raw data to a data buffer of some sort, and then play it back from a set position in the buffer. Or make a feature request for audio delay :)

Or make a feature request for audio delay :)

Audio was top of the list for this FR, probably should have been more specific!  

This feature request is now open for voting. I’ve updated the notes from Team Vuo at the top to describe the planned nodes.