Fire / Time at chosen FPS

Hi ;)

Was wondering it it would be possible to get something like a “Fire at FPS” (and “Allow FPS” for protocols modes) nodes.

Got a new MacBook Pro with ProMotion display up to 120 Hz, now all my compositions run at 120 fps :).
One can change it to 60 FPS in System Preferences, but having to switch it back and forth isn’t that great.

Moreover, when I tried to set it even lower, 48 FPS, I saw I was able to run a Shadertoy cloud shader in fullscreen, which was laggy in 60 Fps.

And while being able to manually switch it in System Preferences is possible, I think a “Fire at FPS” node would still come handy for distribution. If for example you know a given animation would be quite heavy to run at 120 Hz, you could set it at 30 or 60 FPS manually for distribution.
A smooth 30 Hz for heavier compositions will always feel smoother then a laggy 60 Hz ;)

So a node with an input port where you select the frame rate, and you get a time output port refreshed at the chosen rate.

For Protocol Modes and the sidebar Time Input, I don’t know, I guess the team would know best.
Maybe a right click set to “Automatic” by default, but with an option to choose some frame rates ?
Or leave the sidebar as it is, and use the hypothetic node "Allow Time at FPS (or Change Time Framerate) for manual changes.

Right now I tried to limit it with this crude idea showcased below, but set to 1/48 or 1/60, the animation isn’t as smooth compared to manually setting the display rate at 48 or 60 Hz, so this isn’t great but also adds many nodes to the canvas.

Thanks

Fire At X FPS.vuo (4.25 KB)

I’ve run into a few instances where I needed to run a composition at specific frame rate and just used the fire periodically node. I just take the frame rate and divide that number into 1 to get the refresh timing.
For example:

  • 30fps → 1/30 = 0.033333333333333
  • 48fps → 1/48 = 0.020833333333333
  • 60fps → 1/60 = 0.016666666666667  
1 Like

If the point here is to code into a node a way to leverage system graphics settings within the Vuo comp, that sounds really great.  

1 Like

@cwilms-loyalist thank you for your input !

Well right now I hesitate between feeling dumb posting this and still not being sure ;)

I remember testing that but seeing some math patterns in the time output port values, I thought somehow it incremented values and the time output was not the same.

Testing it again seems somehow you’re right, although using Fire on Display Refresh with the screen refresh rate set at 60, the animation seems smoother than using 0.016666666666667, but maybe I’m making it up.

EDIT : But I still think a node where you can choose the FPS in Hz would be easier than having to enter those long decimals each time wouldn’t it ?
As it seems more and more ProMotion displays will arrive, a quick way to choose the settings sounds important ?  

Compare.vuo (2.94 KB)

@Bodysoulspirit,

We could give Fire on Display Refresh a “Target Framerate” input port specified in FPS, and Vuo could automatically select the closest evenly-divisible cadence based on the current display’s configuration. For example, if you pick 25 FPS and the display is set to 75 Hz, Fire on Display Refresh could fire an event for 1 of every 3 display refreshes (exactly 25 FPS). And if you run the same composition on a display set to 60 HZ and and want 30 FPS, Fire on Display Refresh could fire an event for 1 of every 2 display refreshes (30 FPS).

This solution would only work for compositions that use the Fire on Display Refresh node. For protocol compositions and exports (exported Mac apps, using Vuo within other applications (e.g. VDMX), FFGL plugins, or FXplugs), each case would require a different solution. Please create separate feature requests for any of these use cases that you see a need for.

I think these are two (or three perhaps) issues that should not be confused. Time is always time from composition start, not linked to framerate in itself (and framerate/frame-number should never be used to drive animations).

First is the “Fire Periodically” approach. Use a “Divide” node to set the timing - don’t enter decimals manually ;). “1” at input A, then your desired framerate as the divisor. In such a workflow, a “Get System Refresh” node or a “Display refresh time” output from a “System Info” node would be beneficial to make “Fire Periodically” nodes more easy to use (@jmcc). Then it’s just a matter of multiplying the output of this node by an integer to get a subdivision that should match up with the system refresh/draw.

Second is excessive event firing in generators/time input compositions. You don’t want to link this up to framerate either, but rather limit the incoming triggers to a more suitable rate for the HW you got. To do this; attach an event cable from the “Time” input port to the “Increment” port of a “Count within range” node. Set it to a minimum of 1 and a maximum of 2. Drag the output of this to the “Which” port of a “Select Event out (2)” node, and attach the “Time” input port to the event input of the selector. Now you can use the trigger outputs to drive the composition at half the input rate (you can also play around with increasing the max value to get an in-between rate, but then you will skip frames here and there).

Also when going fullscreen on a retina mac with a shadertoy-shader you are rendering at 4K or whatever the retina displays are. That can be pretty heavy, especially for some of the more experimental stuff done there. Try dividing the Width and Height inputs by 2 if you get these from the input ports/screen info node!


Edit: Framerate is linked to time, but only in the sense that you get the time elapsed from composition start based on which frame you are at  

jersmi

If the point here is to code into a node a way to leverage system graphics settings within the Vuo comp, that sounds really great.

Not sure what you mean, but my idea here is to have “Time” ports & Vuo compositions to get refreshed at a given frame rate, for Vuo or Vuo exported stuff, not changing the display refresh rates system wide :).

MartinusMagneson

Thank you for your time.

Yes while I originally tested entering decimals manually, I switched to a Divide or Calculate node later.
Wanted to try without extra events going into the node chain from Fire on Start to execute the Divide node but yes it still should not mess the events.

However,

a)
While the time output ports don’t output the exact same time for Display Refresh vs Divide set to 1/60 (which I hope is not a big deal),

on the newer MacBook Pro I cannot see a difference in the animation, but on the older iMac the Divide method isn’t as smooth (see joined video, it will stutter 2x within the video (funnily enough I don’t see it stutter when using Display Refresh live, but recording the video I still see it stutter on the video for both methods :crazy_face:)).
But ok, the iMac is older, but could the method still not be as efficient ?

b)
I still think a node where you can simply chose the FPS of the Time like suggested by Jean Marie would simplify things and prevent the necessity to use extra nodes ?!

c)
Regarding Protocol compositions, is the method you suggested correct like this ?

If yes, not only does this require even more extra nodes, but also here I’m sadly definitely not getting results as smooth as when setting the display to 60 Hz in the System Preferences, versus setting 120 Hz in System Preferences and dividing it by 2. The frame rate does drop to 60, but the animation ain’t as smooth.

a - Display Refresh :

b - 120 hz ProMotion divided to 60 Hz :

In such a workflow, a “Get System Refresh” node or a “Display refresh time” output from a “System Info” node would be beneficial to make “Fire Periodically” nodes more easy to use (Jean Marie).

Can you explain how that would make it easier ?
If using Fire Periodically 1/60 will always output the same no matter the display no ?

Also when going fullscreen on a retina mac with a shadertoy-shader you are rendering at 4K or whatever the retina displays are

Yes, thank you for mentioning that, will create a separate discussion about resolution etc because I definitely need to spend some time and help understanding that too.

Jean Marie

The suggested “Target Framerate” input port sounds great.
Although I wonder, while it would be great to have it directly on the Fire on Display node without needing extra nodes, won’t it :

a) slow down even slightly the node when you don’t need to change the frame rate ?

b) wouldn’t a Change Time Framerate node allow to change the time also for protocol compositions ? But yeah, would be an extra node that I can imagine to have to add quite often :weary:

So yeah, if it doesn’t slow down the Fire on Display node it sounds better, but what would the different solution for protocol compositions be ? What should I create for a feature request ? Would it be an extra node like Change Time Framerate, or an option on the sidebar ?

PS : you mentioned “exported Mac apps”, but Mac apps can use Fire on Display Refresh can they not ? (screensavers can’t)

Anyway, thank all you guys for your inputs and feedback, joining the comps I used for testing.  

Fire Periodically.vuo (3.16 KB)

Generator - Display.vuo (3.14 KB)

Generator - Divide.vuo (4.62 KB)

While the time output ports don’t output the exact same time for Display Refresh vs Divide set to 1/60 (which I hope is not a big deal)

This is just the info overlay rounding up

Can you explain how that would make it easier ?
If using Fire Periodically 1/60 will always output the same no matter the display no ?

Fire periodically will fire at a set rate, but if it will sync up to your display output rate is something different. This is probably why your older iMac stutters as well. If system framerate is set to 75Hz, and you fire at 60Hz, these only match up every fifth frame. Then it can be a bit hit and miss when you get sync. This is probably why @jersmi wants system setting control, and is why I think a get “system refresh rate” would be neat :).

Thanks Martinus, I get a glimpse of it now :grimacing:

Why is never anything too simple :sob::joy:

1 Like

I appreciate the discussion of the intricacies of the problem :)

The proposed Target Framerate port on the Fire on Display Refresh node would handle the case where:

  • The composition actually has a Fire on Display Refresh node.
  • The framerate needs to sync with the display refresh rate.
  • The framerate is somewhat flexible (e.g. either 25 FPS or 30 FPS would be fine).

This covers most non-protocol compositions, including (to answer your question, @Bodysoulspirit) non-protocol exported apps.

[@Bodysoulspirit] won’t it slow down even slightly the node when you don’t need to change the frame rate ?

It’s such a tiny calculation on each frame that I would expect its effect on performance to be negligible. Of course, if our testing shows otherwise, then we’ll have to figure out a different way to implement it.

[@Bodysoulspirit] wouldn’t a Change Time Framerate node allow to change the time also for protocol compositions ?

It would get us partway there. When you run a protocol composition in the Vuo editor, or an app exported from a protocol composition, Vuo adds some hidden nodes to make it run, including a Fire on Display Refresh node. If the Vuo editor had a setting where you could change the Target Framerate on that hidden node, then you’d be able to control the framerate within Vuo editor and exported apps.

Protocol compositions running within exported screen savers, FFGL plugins, FxPlug plugins, or VDMX would not have a Fire on Display Refresh node, so would require a different solution.

[@MartinusMagneson] Second is excessive event firing in generators/time input compositions… Now you can use the trigger outputs to drive the composition at half the input rate

I think that’s about the best possible solution with the current nodes/functionality available. One way that the proposed Target Framerate would improve on that solution, besides requiring fewer nodes, would be to handle dropped events more gracefully. (If the hidden Fire on Display Refresh node drops an event, then a composition piece that lets every other event through will drop an additional event.)

[@MartinusMagneson] This is probably why @jersmi wants system setting control, and is why I think a get “system refresh rate” would be neat :).

What would be an example of a situation where this would be a better solution than the proposed Target Framerate?

1 Like

What would be an example of a situation where this would be a better solution than the proposed Target Framerate?

Not sure if better, but maybe a couple different ways of looking at it. I would assume @jersmi 's method would result in lower system overhead in total, considering fewer (duplicate) frames. As someone that deals with broadcast equipment a lot (looking at you Blackmagic), along with Powerpoint that does exactly this, I can hardly say I’m a fan of the approach.

With a “get system refresh rate” you can easily divide it with any integer to get a subdivision of the framerate. That way you can not only trigger at half framerate, but also get every fifth frame for instance - for less important/time sensitive tasks.

get every fifth frame for instance - for less important/time sensitive tasks.

In that case, would the timing of the task even need to be tied to the framerate, or could you use Fire Periodically (and then merge the result into the Fire on Display Refresh event stream if needed)?  

FirePeriodicallyAndMerge.vuo (3.35 KB)

would the timing of the task even need to be tied to the framerate…

I guess not! It would just need to be the update frequency so that you could do the operations via nodes.

The approach hinges on user philosophy though. I’m all for less specific-task nodes, and building subcompositions. Not everyone agrees with that though.