» VL: Patch Your Own Mainloops
This site relies heavily on Javascript. You should enable it if you want the full experience. Learn more.

VL: Patch Your Own Mainloops

Welcome dear patchers to a new episode of devvvvs giving you control over your PC mainboard.

When you work in vvvv or VL the evaluation of your patch is automatically driven by a mainloop. It executes the nodes in your patch (usually) 60 times per second and by this allows changes to happen in your patch over time.

If you have a look at the PerfMeter in a renderer with a mainloop timer without any tweaks you will see lots of flickering like this:

Those flickers indicate that the time between two frames of the mainloop is changing a bit every frame. In an ideal world those flickers would not be there and the time between two frames would always be the same. An unstable mainloop like this creates jitter in animations, drops video frames and lets the visual output of your patch look less smooth.

It's quite a difficult task to get high-precision timer events on a modern computer architecture. Timers and me go way back to the early vvvv days at MESO when i worked on the vvvv mainloop and the Filtered time mode. Since then we could improve the vvvv mainloop time stability quite a bit by doing tricks like changing the windows system timer resolution and introducing a short busy wait phase at the end of the mainloop. The result of this work looks like this:

The experience gathered from the vvvv mainloop improvements is now available in the VL library, so you can build your own sub-mainloops.

But why would you need your own timer at all if you have a good mainloop already? There are a few reasons:

  • Have a second mainloop on a different thread to split performance or don't block the mainloop
  • Process something at a slower rate as the mainloop to save performance, e.g. web requests every few seconds
  • Process something at a higher rate as the mainloop, e.g. output to a micro controller or servo motor
  • Run parts of your patch in it's own mainloop to avoid blocking user input from vvvv

General Node Design

In VL the patch of a process node by default has a Create and an Update operation. Create gets called once an instance of the process is created and Update gets called periodically by the mainloop. In this process node patch you can place other process nodes that 'plug into' those two operations by placing their own Create on the Create of the surrounding patch and their Update on the Update of the surrounding patch.

This is the same for stateful regions like ForEach [Reactive], only that the Update of the ForEach region doesn't get called automatically by the surrounding patch but gets called by the events of the incoming observable. More on that in this blog post: VL: Reactive Programming

There are many sources of observable events. For example Mouse, Keyboard and other input devices as well as AsyncTask or MidiIn. The timer nodes work in the same way. The output is an Observable that is on a new thread and either sends the frame number (for the system timer nodes) or a TimerClock (for the MultimediaTimer or BusyWaitTimer). A patch would look like this:

The use of observables also makes it easy to swap one timer for another if neccessary.

Basically there are 3 ways to setup timers in windows and now VL has them all!

System Timer

This is the most common timer but it usually only has a precision of 16ms. It can be used for recurring events when accuracy is not the most important issue and the interval is in the seconds range or a higher millisecond range. Nodes that use these timers are for example Interval and Timer in category Reactive:

Multimedia Timer

This is a dedicated timer for applications that do video or midi event playback. It is fairly accurate to about 1ms and doesn't need much CPU power. So it can be used for most time critical scenarios. To use this timer, make sure you enable the Experimental button in the VL node browser and create the node MultimediaTimer:

So that's nice, but it has two little draw backs. You can only specify the period in whole milliseconds and as you can see there is still some flickering in the measured period times. The flickering is well below 1ms but still, we can improve that:

Busy Wait Timer

Since its possible to measure time with high accuracy, one can write an infinite loop that always checks the time and executes an event once the specified interval time has passed. This timer always uses 100% of one CPU core because it checks time as often as it can. But hey, how many cores do you have these days? With this method you can achieve precision in the micro second range, which is insane!

If any patch processing is happening on the timer event, the power of your core is of course shared with the busy wait. Just make sure that the processing doesn't take longer as the specified period:

This timer has an option to reduce CPU load for period times that are higher than the accuracy of your system timer. You can specify a time span called Wait Accuracy. This is a time span before the desired end of the period that specifies when the busy wait phase should start. Before that time the timer is set to sleep for 1ms periodically. 16ms is a safe value, but you can decrease it until the Last Period starts to jump in order to reduce CPU load even more.

Threading

Both the MultimediaTimer and the BusyWaitTimer start their own background thread with priority AboveNormal. The thread priority setting might become an input pin in the future.

So now download latest alpha, enable the Experimental button in the VL node browser and give it a shot. If anything unexpected happens, let us know in the forums.

yours,
devvvvs

tonfilm, Wednesday, Apr 18th 2018 Digg | Tweet | Delicious 7 comments  
sebl 19/04/2018 - 13:49

\o/

lasal 23/04/2018 - 18:03

Niiice

StiX 26/04/2018 - 00:19

this could perform really well when building sequencer in vvvv right?

tonfilm 26/04/2018 - 13:46

@StiX yes, the multimedia timer is usually used for midi sequencing and video playback. so with that driving a BinarySearch and the reactive midi nodes you can patch a proper note or drum sequencer.

colorsound 02/05/2018 - 15:14

Hi,sounds very good.

will this help to create a better clock to sync generative ,boygrouping and videos in a multi computer scenario ?

any infos or example in this matter welcome.

cheers

tonfilm 02/05/2018 - 17:51

@colorsound this article is about using clocks to get precise timer intervals, it's not about synchronizing PC clocks over network. so in a sense related, but different problem.

colorsound 02/05/2018 - 18:07

@tonfilm, yes i know is diferent internal clock but i thought it could somehow improve the multi computers clock.

Thanks

  • 1

anonymous user login

Shoutbox

~1h ago

io: A vvvvery vvvvriendly vvvvestival, ed. 2018 http://keroxen.com/

~1d ago

microdee: @synth: use beta37 for Notuiv and install it with vpm. this article describes why md.ecosystem-update

~1d ago

mburk: @synth Check github for superphysical Beta37. Deferred+Forward Branch.

~2d ago

synth: Getting red nodes on VL stuff, mostly SuperPhysical, Notuiv and CraftLie. Only me or there is something broken?

~2d ago

joreg: reminder: we'll do a #vvvv #vl workshop as part of #retune18 in #berlin this friday: vvvvvl-workshop-at-retune-2018 #visualprogramming #dotnet

~6d ago

tonfilm: how about debugging your #dx11 #GPU frames? debug-dx11-frames-with-nvidia-nsight

~8d ago

mrboni: Anyone know where I can get an Etherdream ILDA unit in the UK / West Europe delivery this week?https://ether-dream.com/

~9d ago

tobyk: @catweasel Re:KiNet yes, its pretty similar to artnet but with some different magic numbers. I can send you what I've used before.

~10d ago

microdee: @Hadasi: "read the field manual" I knew a slightly more explicit version of that abbreviation :D