Is it possible to achieve an absolutely constant frame rate in Jitter? I would like to trigger some sounds with physics objects (and other sources of matrix data) but I would need some accurate timing/frame rate? Is there any way to do that?

constant-frame-rate

i dont think so, this is very untypical for video apps and/or the way they display movies.

dont you have the option to use 50 or 60 frames - or even 100? that should be just fine.

Yeah I would be happy with 50 or 60 fps which is what I have but the frame rate is obviously not constant. So for instance if you trigger MIDI events with constantly pulsating collisions, let's say that falling balls trigger a kick drum, you get unwanted delay between beats whenever frame rate drops. And the frame rate significantly drops as you interact with a patch or openGL environment. So I tried with 20 or even 10 fps, in hope that I would be on a safe side when interacting with a patch, but I just can't avoid relatively big frame rate fluctuations which is about 10% to 20% of average frame rate.

PS: I am using late 2013 macbook pro, 2,6 GHz Intel Core i7, 16 GB 1600 MHz DDR3, NVIDIA GeForce GT 750M 2048 MB. OSX 10.9.4.

PS2: And if I trigger audio events in groove~ or play~ object frame rate falls from 60 to 20, but when I use exactly the same method of triggering only that I do the audio part in Ableton, frame rate falls only for 2 fps in average, which is enormous difference. So if I send MIDI to Ableton and use a sampler there "everything works fine" but when I use groove~ or play~ is a total no go. And of course I don't want to turn on the scheduler in interrupt although it doesn't make much difference.

There are many many things that can affect this kind of timing critical systems. I spend a great deal of time optimizing my Jitter+MSP patches to get stable and reliable performance. Without seeing your patch it's hard to give any to the point advice. (I'm not promising I can check your patch if you post it. Running up against big deadlines here...)

I suggest you create a sort of quantize system on the MaxMSP side using onebangs or snapshot~ for msp.

Create a mother sequence trigger clock(phasor~ or counter or rate~ etc...)

hook up the [onebang] module and voilà, if an event/collision is detected in the physics world,

trigger it on the next 16th or 32nd or 64th note.

Hope this helps or inspires a different approach for you :-)

Say you want to create solid beats
I suggest you create a sort of quantize system on the MaxMSP side using onebangs or snapshot~ for msp. 

Create a mother sequence trigger clock(phasor~ or counter or rate~ etc...) 

system:
hook up the [onebang] module and voilà, if an event/collision is detected in the physics world,
trigger it on the next 16th or 32nd or 64th note. 

Hope this helps or inspires a different approach for you :-) 

@PHIOL: The quantisation is unfortunately not good enough solution for what I need...because the frame rate occasionally fluctuates to much. Constant frame rate I guess is the only solution...so I was hoping that there is some "qlim trick" that would prevent fluctuations. For instance if I get fps in the range between 40 and 60 then "qlim at 30" should do the job...but it doesn't.

@DTR: The patch will grow from small to enormous through time so I guess it wouldn't make any sense if you would take a look at a patch at this point, but thanks anyway for your offer!

Is there any "qlim or something" that would stabilise frame rate?

@PHIOL: The quantisation is unfortunately not good enough solution for what I need...because the frame rate occasionally fluctuates to much. Constant frame rate I guess is the only solution...so I was hoping that there is some "qlim trick" that would prevent fluctuations. For instance if I get fps in the range between 40 and 60 then "qlim at 30" should do the job...but it doesn't. 

> Is there any "qlim or something" that would stabilise frame rate?

Again, there are too many factors potentially involved to give you a generic answer. Even flaky graphics card drivers could mess things up. If your set up/patch is right you should be able to get a steady fps by driving jit.gl.render from a qmetro. In my current system the max fps I cqn squeeze out oscillates around 180fps, but is not steady there. I set the qmetro to 120Hz, so lower than the absolute max it can get, and it stays at that, with very slight variations within 1 fps.

If you're system is going to grow huge you better get this right from the start or you might be building on something that 's flawed in its foundation.

My system uses 2 kinects, xbee wireless sensors, 4 projectors and 4.1 audio, so yes, it's pretty big.

Again, there are too many factors potentially involved to give you a generic answer. Even flaky graphics card drivers could mess things up. If your set up/patch is right you should be able to get a steady fps by driving jit.gl.render from a qmetro. In my current system the max fps I cqn squeeze out oscillates around 180fps, but is not steady there. I set the qmetro to 120Hz, so lower than the absolute max it can get, and it stays at that, with very slight variations within 1 fps. 

If you're system is going to grow huge you better get this right from the start or you might be building on something that 's flawed in its foundation. 

My system uses 2 kinects, xbee wireless sensors, 4 projectors and 4.1 audio, so yes, it's pretty big.


depending on the graphics you need to display in the end you could try to process the open GL objects as parts, do that with a framerate of 400, and then later downsample those video frames with interpolation.

you will often find that video does not respond to message input as quick as audio signals do. but since your eyes only require 25 fps, there is always a workaround/possible implementation. having the desired fps appearing in a more stable fashion would, in my opinion, not really solve the problem.

when you say that your framerate drops down to 2 when you turn on audio, you should consider to adopt some measures in order to save processing power. ask yourself if you really need to display that bouncing ball in 4k at 64 bit color using 20 tracks.

Although Roman DTR real great logical answers

have you tried passing your matrices through a speedlim

Although Roman DTR real great logical answers 

have you tried passing your matrices through a speedlim 

"when you say that your framerate drops down to 2 when you turn on audio, you should consider to adopt some measures in order to save processing power. ask yourself if you really need to display that bouncing ball in 4k at 64 bit color using 20 tracks."

if I send trigger messages to ableton (to some fancy VST synth or sampler) or AU DLS Synth 1 (the ultimate MIDI piano) the frame rate drops for about 1% which is awesome. If I trigger play or groove objects in the same way frame rate drops hugely.

I'll transform the patch into something shareable ASAP and we'll (hopefully) continue from there. Just need to try some different solutions first in order to give you the most optimised patch as I can do it (as in a way suggested by DTR). And also I need to make one patch from three different ones as it is in the moment.

what would do the magic would be to write the frames in a register and retrigger them from there using a metro in overdrive.

but you would now also need a pwindow which allows to work in overdrive. no idea, but i guess it would not even be possible to write such an object, leave alone that it already existed.

render the ball movie with 1000 fps, then replay it at different speeds. can you say "video sampling synth"?