Re: timing of jit.qt.grab when reading and writing matrixes

Forums > Jitter > timing of jit.qt.grab when reading and writing matrixes
Jan 27 2013 | 9:59 pm

Hi karl,
I’ve got some experience with writing and reading files, for a perforamce called KKQQ ( ). I’had to record three different streams of video (WI-FI streams) and three streams of sound (one by actor) on SSD. The difficulty was each one played his partition at a different rate, the first one played in front of the camera at half the speed, the second one 0.66 the speed and the third at 0.75 the speed. When the performance began they were still playing in their boxes since 45min for the first, 30min for the second and 15min for the third. The performance began with the projection and they appear synchronized, technically the first plays at the rate of 2, the second at a rate of 1.66666 and the third at 1.33333. Voices are pitched even if they’ve tried to speak with lower voices (& slow motion gestures) at recording. So as a result at the beginnig of the performance I’m recording 3 video streams, 3 sound streams ( because they continue to record during the whole play until the projection catch the live action after 45min) and reading 3 video streams and 3 sound streams. I’ve recorded on little movie each 300 frames (something like 210 movie per actor) same for sound. Naming ( -> ), recording and writing was automatic after the 300 frames there was a switch to a second recorder ready to record. On the other hand for projection there were two players with selecting movies or sound, reading and playing in a similar automatic way with a switch betwen the players.

1. I’ve tried recording matrices but i’ve found that it was better to record little movies or chunks to avoid write and read operations (~ 2500 cumulated in a 90 minute perf between read and write are a lot i thought.)
2. I’ve forced the jit.qt.record to grab images to be synchronized with the sound with the little attached patch and these msp setting (48000khz with I/O vector size and signal vector size both set to 128 overdrive on). That give me one bang exactly every 40ms. In the other hand the projection was handled with a jit.qball after the little patch because forcing with the samee clock freeze Max and the little décalages or delays (glitch) were found funny by the audience.

Hope it can help you


  1. delta.maxpat

Subscribe to the Cycling ’74 Weekly Newsletter

Let us tell you about notable Max projects, obscure facts, and creative media artists of all kinds.

* indicates required