jersmi's picture

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

Component: 

Notes from Team Vuo

Vuo Pro: 

No — available with both Vuo CE and Vuo Pro

Complexity: 

●○○○ — Up to a few days of work

Potential: 

●○○ — Appeals to current community

Nodes to add:

  • Delay Event
  • Delay Value
    • input:
      • Time (real number)
      • Value (generic type)
      • Seconds (real number)
    • output:
      • Delayed Value (generic type)

Related feature request: Make it easier to play back video with a time delay, a solution specific to video and other streams of data.

Comments

You kind of have it in the

MartinusMagneson's picture
Submitted by

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.

https://vuo.org/user/3272,

cwilms-loyalist's picture
Submitted by

https://vuo.org/user/3272, 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

MartinusMagneson's picture
Submitted by

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.

keithlang True! But then

MartinusMagneson's picture
Submitted by

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 :)

Feature status

  • Submitted to vuo.org
  • Reviewed by Team Vuo
  • Open for community voting
  • Chosen to be implemented
  • Released

When we (Team Vuo) plan each release, we try to implement as many of the community's top-voted feature requests as we have time for.

If anyone would like to help this happen sooner, we're also accepting open source contributions and commissioned work.

More info about how Vuo feature requests work

Votes

10 votes so far!

Who voted?

jersmi's picture