karl krach

i'm wondering wether it can make sense to bind the main system pulse (which would be a metro usually) to a jit.qt.grab @unique... it seems to work quite ok in my patch but since i have never seen anything close in any patcher (rather quite the opposite) i am just wondering wether i am missing something...

background: i'm working with a rather extensive patch dealing with recording of live video via jit.qt.grab, then saving this to .jxf-sequences which then get played back interactively while recording continues... since i do not want to have double frames in my jxf-sequences and the smoothness of the system is anyway determined by the framerate the camera produces (which is a solid 720p50 or 1080p25 coming from hdmi via a blackmagic ultrastudio device) i guess it does not make much sense to have the rest working any faster... or am i missing something here?

the following patch is not working but shows what i mean... any suggestions are highly appreciated!

hello everybody,
i'm wondering wether it can make sense to bind the main system pulse (which would be a metro usually) to a jit.qt.grab @unique... it seems to work quite ok in my patch but since i have never seen anything close in any patcher (rather quite the opposite) i am just wondering wether i am missing something...

triggering-and-qmetro-bind-timing-to-jit-grab

I haven't opened your patch, but the technique you describe works great. I remember reading about it on the forums here and there and now I use it all the time. (I think it's been called "frame-driving" possibly initially introduced by Vade?) It doesn't escape from the inherent scheduler instability of MAX (see age old threads about HD playback) but I think it's as efficient as we can get. Also keep in mind that MAX uses the "old" Quicktime methods for capture, which are reported to be slower than the "new" IOKit methods that are used by modern software so you might not get guaranteed frame rates. (Ask Cycling about this and they say IOKit would hurt their cross-platform compatibility. Meanwhile we still can't play (or capture) industry standard formats without hiccups, even on ridiculous 12 core computers.)

Have you used the Black Magic device as an audio input in MAX? With my Intensity Pro PCI card (and Matrox MXO2 mini) I get an instant MAX crash every time I turn on the audio if I've selected the capture device as my audio input (MAX 6.08, OS 10.7.5). Any luck?

i did not find much on "frame driving", you do not happen to have an example lying around? - i'm just curious how other people did it...

about the ultrastudio in max: to be frank, i never used any audio in max at all so i 'm not even sure what you mean by "turning it on". i just tried to start up max and started this audio tester with the card connected but i do not find anything were i could choose the input source... but if you send me some patch or tell me what to do i will gladly try and see what happens over here...

most interesting!
i did not find much on "frame driving", you do not happen to have an example lying around? - i'm just curious how other people did it...

I probably got the name wrong, sorry. This thread 

https://cycling74.com/forums/smooth-video-playback

 covers it (along with some other important and non-obvious tricks). They are discussing jit.qt.movie playback but the same wisdom applies to capture.

If you want to test audio with the BlackMagic device, go to Options menu / Audio Status... and set your Input Device and Output Device to BlackMagic Audio. In that window, switch the audio from Off to On. When I do this it crashes MAX instantly. I wonder if the same happens to you?

I probably got the name wrong, sorry. This thread https://cycling74.com/forums/smooth-video-playback covers it (along with some other important and non-obvious tricks). They are discussing jit.qt.movie playback but the same wisdom applies to capture.

thanks for the link! i'll have a read through that!

about ultrastudio and audio: yes, it crashes over here too. instantly and as soon as i select the blackmagic device as audio device - regardless wether i choose it as input or output. :(

thanks for the link! i'll have a read through that!
about ultrastudio and audio: yes, it crashes over here too. instantly and as soon as i select the blackmagic device as audio device - regardless wether i choose it as input or output. :(


since i run into some problems with that, i thought i revamp this thread for maybe getting some more explanation.

my question is: how does performance influences the timing across a patch?

using the method described above, i have a fast metro running at "2" which feeds into a jit.qt.grab set to unique@1 to drive the rest of my patch (at 50 fps).

now, what i don't understand: if i measure the speed of the metro right at its outlet and BEFORE getting slowed down by the jit.qt.grab, to my understanding, it should show 500 fps (one every two milliseconds). the jit.fpsgui however shows a maximum of 100 fps and most of the times, the fps is quite close to the 50 fps speed of the jit.qt.grab (which comes later in line).

why? is there any documentation explaining how timing in max works and how general performance affects overall timing?

since i run into some problems with that, i thought i revamp this thread for maybe getting some more explanation.
my question is: how does performance influences the timing across a patch?

a little example:
using the method described above, i have a fast metro running at "2" which feeds into a jit.qt.grab set to unique@1 to drive the rest of my patch (at 50 fps).
now, what i don't understand: if i measure the speed of the metro right at its outlet and BEFORE getting slowed down by the jit.qt.grab, to my understanding, it should show 500 fps (one every two milliseconds). the jit.fpsgui however shows a maximum of 100 fps and most of the times, the fps is quite close to the 50 fps speed of the jit.qt.grab (which comes later in line).

why? is there any documentation explaining how timing in max works and how general performance affects overall timing?
thanks and all the best
k


Interesting that Cycling should say IOKit would hurt x-plat compatibility - while this is probably true . . . I don't think anyone on the Windows side of the equation is too thrilled about the Quicktime dependency, or OpenGL for that matter.

triggering and qmetro - bind timing to jit.grab?