Refresh FPS and monitor controller issue
-
I use 3 monitors in my control panel, all previewing results of some fairly fast movie clip cutting/mixing. Am using HAP encoded movies (vid-gpu), on a high-specd 16" MBP, with General Preferences set to Target Frame Rate = 30fps, Display Refresh Lock = Scaled (Recommended), General Service Tasks = 30x Per Frame and am very happy with the projector output performance... BUT the monitor previews are playing at about 20fps, so i have to mix off the main projected screen (sometimes up to 100m away) and not the preview monitors (which i'd prefer).
I've tried adjusting each monitors "fps limit" to 0 and 30 but doesn't seems to make any difference.
A couple of years ago the bug that Stage Preview and Monitor controls do not respect the FPS settings was logged as an issue in the bug-tracker re https://community.troikatronix...
Is this still a bug in v3.1.1? (If so, am assuming this is what i'm encountering - right?)
Am also assuming it must be a hard bug to fix? If so, i can learn to live with it until it's resolved, since Isadora brings me so much joy.
Mr J
-
@mr_j I just took a look at this, and what I see is that the Monitor does respect the framerate set. I am however testing this with lower framerates so that I can see the difference clearly. If I set the framerate of a monitor to 1fps, its clear that it runs at 1fps, and if I then increase this to 4fps, the difference is also clear.
Will a 30fps video playing, it appears to me that the monitor is playing at the same rate (perhaps a frame of latency).
I have seen your VJ project, so I know its pretty heavy. You may experience better performance reducing your cycle rate from 30x to perhaps 5X. This number is how many times per video frame the patch is processed, and generally this has little effect on the output as long as it remains above 1x the framerate (I use 2X as a point to auto reduce my projects.. eg: switching on some downsampling)
What cycle rate does your project report to you when you are running it?
In Isadora 3 the UI have been decoupled from the playback engine. This helps ensure that interacting with the Isadora UI won't delay video playback. It also means that data is passed between the playback engine and UI thread. Its possible that this becomes a bottle neck in your case when you are using numerous monitors and have a heavy load. It might be possible to optimize somewhat by combining videos in the patch into a single video (eg: 2x2 quad) that is sent to a single monitor. I have not tested/confirmed this optimization, but it seems feasible.