My issue with your first suggestion (sending output from Max to Syphon Recorder) is that I’d like to stop and start recording automatically. I’d like to be able to set the maximum file size of the clips so that it doesn’t take too long to load a given clip into jit.gl.hap (and to be able to adjust this maximum file size to optimize for a given hardware config and patch). Another reason for this chunking approach is that, as I understand it, Hap clips can’t be read into jit.gl.hap until they’re closed (i.e., until one stops recording in Syphon Recorder). For the application I have in mind, it would be good to be able to scrub through a given chunk of recorded video as soon as possible, and to switch between chunks as necessary.
I’m not sure if it clarifies what I want to do, but essentially I’d like to have something like a long-duration loop recording system, similar to what you might have in a traditional video surveillance rig. I’d like to be able to pull up and scrub through any region of video that happened within the past half hour. I realize that there are some likely technical problems with the chunking solution I’m proposing (e.g. missing video during the time it takes to close one file and start writing to the next, as well as the inability to scrub smoothly through a region of interest that spans multiple files), but it’s a point of departure – would be happy to hear alternate suggestions.
I could certainly build a patch routing Syphon Streams to jit.qt.record, but I was under the impression that since jit.qt.record is a CPU-side object this would be more computationally expensive than whatever method Syphon Recorder is using (even using some of your optimization methods, like switching to UYVY for the readback operation). Do I understand you correctly in saying that recording Hap via jit.qt.record would be equally efficient to using Syphon Recorder, though?
Thanks for your time, Vade – I’m heavily indebted to you for making much of my work possible.