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
Other Attachments:
| Attachment | Size |
|---|---|
 Fire At X FPS.vuo | 4.25 KB |
Comments
I've run into a few instances
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:
If the point here is to code
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.
Chris thank you for your
@cwilmsloyalist 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 Refreshwith 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
Bodysoulspirit,
@Bodysoulspirit,
We could give
Fire on Display Refresha "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 Refreshnode. 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 issues
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
jersmi
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
DivideorCalculatenode later.Wanted to try without extra events going into the node chain from
Fire on Startto execute theDividenode 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 RefreshvsDivideset to 1/60 (which I hope is not a big deal),Capture d’écran 2021-12-25 à 23.09.59.png
on the newer MacBook Pro I cannot see a difference in the animation, but on the older iMac the
Dividemethod isn't as smooth (see joined video, it will stutter 2x within the video (funnily enough I don't see it stutter when usingDisplay Refreshlive, but recording the video I still see it stutter on the video for both methods 🤪)).But ok, the iMac is older, but could the method still not be as efficient ?
Regular - Divide.mov
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 ?
Capture d’écran 2021-12-25 à 20.43.58.png
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 :
Protocol - Display Refresh.mov
b - 120 hz ProMotion divided to 60 Hz :
Protocol - Divide 120 to 60.mov
Can you explain how that would make it easier ?
If using
Fire Periodically1/60 will always output the same no matter the display no ?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 Displaynode 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 Frameratenode 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 😩So yeah, if it doesn't slow down the
Fire on Displaynode 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 likeChange Time Framerate, or an option on the sidebar ?PS : you mentioned "exported Mac apps", but Mac apps can use
Fire on Display Refreshcan 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
Generator - Display.vuo
Generator - Divide.vuo
While the time output ports
This is just the info overlay rounding up
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
Thanks Martinus, I get a glimpse of it now 😬
Why is never anything too simple 😭😂
I appreciate the discussion
I appreciate the discussion of the intricacies of the problem :)
The proposed Target Framerate port on the
Fire on Display Refreshnode would handle the case where:Fire on Display Refreshnode.This covers most non-protocol compositions, including (to answer your question, @Bodysoulspirit) non-protocol exported apps.
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.
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 Refreshnode. 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 Refreshnode, so would require a different solution.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 Refreshnode drops an event, then a composition piece that lets every other event through will drop an additional event.)What would be an example of a situation where this would be a better solution than the proposed Target Framerate?
What would be an example of a
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
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 theFire on Display Refreshevent stream if needed)?FirePeriodicallyAndMerge.vuo
would the timing of the task
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
The approach hinges on user philosophy though. I'm all for less specific-task nodes, and building subcompositions. Not everyone agrees with that though.