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