6.1 64-bit Memory Leak in jit.matrix or jit.gl.videoplane?

    Mar 15 2013 | 5:14 am
    I'm working on a REAM-based video delay. I tried the 64-bit version to allow a longer delay time, i.e. mroe RAM, but there's a memory leak in the 64-bit version that doesn't appear in the 32-bit version.
    Here's the patcher:
    Sub patcher, Delay Matrix:
    I modified and expanded upon a similar patcher from the forum and also a help file patcher. I'm using many of those DelayMatrix subpatchers to get enough of a delay, but the leak is evident with just the one. Thanks, Andrew

    • Mar 15 2013 | 6:57 am
      hi andrew. thanks much for the patch and the bug report. the memory-leak culprit is actually the 64-bit jit.qt.grab.
      we'll get it fixed up.
    • Mar 15 2013 | 12:16 pm
      a suggestion for a workaround: I worked in a project where I head to deal with huge delays (like 4 hous). What I made was record the grabbed video into clips and then play it back. The clips were about 10 min each. The odd thing about this is that I created a counter that went till, let's say, 24. After reaching 24, it started counting again and the vifeo files were overwritten. In other words: I could kept always 4 hours o video delay in my HD. Hope it helps.
    • Mar 15 2013 | 12:59 pm
      No problem, Rob.
      sandroid, multiple HDD clips is a great idea. I had avoided that because the installation will run for 12-14 hours a day, and I didn't want to create a massive file on the drive. I could just record 3 or 4 small files and cycle through them. Thanks!
    • Mar 15 2013 | 1:09 pm
      Rob, I forgot to ask another question: Is there a specific capacity for a jit_matrix? Or rather how do I calculate it? I'm currently using a 3D jit.matrix that depending on the XY dimensions has a hard limit to its max Z value, but I couldn't figure out how to calculate it. Multiplying the 3 dimensions and then by 4 for the plane count per effective Z layer, produced widely different numbers for a variety of XY sizes. Thanks, Andrew