Tim C

I have been working this patch up for a while and keep getting stuck with my output frame rates. I've read the jitter best practice docs, forum posts and the like but keep getting stuck at the 18FPS mark on my output videos. I feel like I must be missing something here, as I've tried to trim as much processing off each part of this patch.

Concept is to have video clips effected by musical input. internal patch is a 4 track audio player. Left hand side of the patch is line generators for the fades and effects. Keys input messes with mirror/flip via Slab. All of these processes have Coll object to provide variation

Maggie Video Audio 3.7.maxpat

Any light someone could shed on this would be a great help.

I have been working this patch up for a while and keep getting stuck with my output frame rates.  I've read the jitter best practice docs, forum posts and the like but keep getting stuck at the 18FPS mark on my output videos.  I feel like I must be missing something here, as I've tried to trim as much processing off each part of this patch.
Concept is to have video clips effected by musical input.  internal patch is a 4 track audio player.  Left hand side of the patch is line generators for the fades and effects. Keys input messes with mirror/flip via Slab.  All of these processes have Coll object to provide variation


Any light someone could shed on this would be a great help.
Thanks!

Hi all, 
I have been working this patch up for a while and keep getting stuck with my output frame rates.  I've read the jitter best practic

jittergl-frame-rate-issues

I didn't test it thoroughly, but I've noticed that you have a jit.world in the patch AND a qmetro 33 and that you're sending the qmetro to the jit.movie objects. Currently there's no need for explicit banging of the jit.movie objects (unless they're in automatic 0), they communicate with jit.movie directly. By sending the qmetro explicitly, I think you're triggering and therefore doing all the subsequent processing calculations twice... does it help?

Exactly, you don't need to send a metro to the jit.movie object if has @output_texture 1, just set the drawing context with @drawto and @automatic 1

And use a jit.gl.asyncread between jit.world and jit.vcr!

By the way, jit.vcr has an error, you need to write "@codec h264" (you're missing the @codec attribute).

If performance doesn't increase, don't capture to disk inside Max, do it externally, using Syphon on Mac, Spout on Windows, or other GPU accelerated screen capture utility.

And use a jit.gl.asyncread between jit.world and jit.vcr!
By the way, jit.vcr has an error, you need to write "@codec h264" (you're missing the @codec attribute).
If performance doesn't increase, don't capture to disk inside Max, do it externally, using Syphon on Mac, Spout on Windows, or other GPU accelerated screen capture utility.

no need to use jit.gl.asyncread when you are using jit.world @output_matrix 1, jit.world uses an internal asyncread object for this (as of max 8.0 i believe), as long as matrix_mode_async is enabled (which it is by default).

Thanks so much for this info. I tried a number of things and got to 28fps, Frame rate increased slightly when removing qmetro bangs, however most noticable was removing preview from jit.world

I'll look into Syphon for capture because I am still getting some lag and would like the vision to be smooth.

Currently I'm reading 4x videos using $1 in read command and numbers in filename, is there a way to buffer these all into the patch and avoid reading from disk? I getting some lags in this operation I believe

Maggie Video Audio 3.9.maxpat

Hi guys, 
Thanks so much for this info.  I tried a number of things and got to 28fps,  Frame rate increased slightly when removing qmetro bangs, however most noticable was removing preview from jit.world

Jitter/GL frame rate issues