Jimmy

Hi - just re-posting this from previous post as it is a seperate question and nothing to do with previous post.

When running this patch for more than 20 minutes, the patch uses up all my hard drive space (about 2.5. gb free)

Since i'm not writing to disk, this shouldn't happen - right?

Do i need to clear the kill the grab object after every loop or something?

hard-disk-full

400 * (320 * 240 * 4 * 8bytes) / 1024 = 960000K / 1024 = 937.5MB

How much RAM do you have installed on your system? I am pretty certain 

this is your computer paging virtual memory to disk. Especially since 

there's no writing to disk going on in the patch.

How much RAM do you have installed on your system? I am pretty certain 
this is your computer paging virtual memory to disk. Especially since 
there's no writing to disk going on in the patch.

Note that you are using quite a bit of ram in this patch and If 

you've increased the jit.matrixset sizes it could be even more. With 

the default 200 matrix for each matrixset sizes, we have:

320 x 240 x 4 x 200 x 2=122,880,000bytes == ~122MB

If you were to change the matrixset sizes to be something like 2000, 

you would use almost 2GB and this would get paged to disk on any VM 

system (XP or OS X). So far with your patch, I don't see any memory 

leak that would otherwise cause RAM to grow over time, or any disk 

writing in your patch. So I'd need to know more information about 

your exact usage of this patch, before I could speculate further.

Btw, int->[prepend index]->[prepend set]->message box, is probably 

more efficiently (and clearly) represented as int->[pack index 0] 

then just bang the left input of pack instead of banging the message 

Note that you are using quite a bit of ram in this patch and If  
you've increased the jit.matrixset sizes it could be even more. With  
the default 200 matrix for each matrixset sizes, we have:

If you were to change the matrixset sizes to be something like 2000,  
you would use almost 2GB and this would get paged to disk on any VM  
system (XP or OS X). So far with your patch, I don't see any memory  
leak that would otherwise cause RAM to grow over time, or any disk  
writing in your patch. So I'd need to know more information about  
your exact usage of this patch, before I could speculate further.

Btw, int->[prepend index]->[prepend set]->message box, is probably  
more efficiently (and clearly) represented as int->[pack index 0]  
then just bang the left input of pack instead of banging the message  
box.

I'm using a powebook G4 with 1gb of RAM and was still gettng the problem when using a matrixset size of 100.

If i supply more hard drive space will it stop the problem, or will it just continue to take whatever space i give it?

It's for an installation which is to run for about 2 days.

Then it sounds like a memory leak either in Jitter or the video 

capture device driver. I'm not seeing the problem here on my G4 

AluBook running 10.4.5 and my latest development version of Jitter, 

so it might be a bug in an earlier version of Jitter, though I don't 

recall having such problems with similar setups in any version in the 

past (have used patches which make use of these elements and more for 

several hours at a time without problem). Could you please clarify 

your video input device, whether you installed drivers for this 

device, as well as what version of Jitter, MaxMSP, and the OS you are 

Also, it would help us out If you could also take some time to 

isolate what part of the patch is leading to this behavior. For example:

- Does it happen when you replace jit.qt.grab with jit.qt.movie?

- If you're running OS X, and you run process viewer or "top" from 

the terminal, does the MaxMSP memory usage keep growing as your patch 

runs? (for more info on these and other memory viewing utilities 

http://www.osxfaq.com/dailytips/03-2002/03-18.ws)

- If you remove the jit.matrixset portion of your patch (just use a 

single jit.matrix) is the behavior the same?

- Is any other patch open or are any other applications on the system 

growing their memory usage without bound?

Then it sounds like a memory leak either in Jitter or the video  
capture device driver. I'm not seeing the problem here on my G4  
AluBook running 10.4.5 and my latest development version of Jitter,  
so it might be a bug in an earlier version of Jitter, though I don't  
recall having such problems with similar setups in any version in the  
past (have used patches which make use of these elements and more for  
several hours at a time without problem). Could you please clarify  
your video input device, whether you installed drivers for this  
device, as well as what version of Jitter, MaxMSP, and the OS you are  
using?

Also, it would help us out If you could also take some time to  
isolate what part of the patch is leading to this behavior. For example:

- If you're running OS X, and you run process viewer or "top" from  
the terminal, does the MaxMSP memory usage keep growing as your patch  
runs? (for more info on these and other memory viewing utilities  
check out http://www.osxfaq.com/dailytips/03-2002/03-18.ws)

- If you remove the jit.matrixset portion of your patch (just use a  
single jit.matrix) is the behavior the same?

- Is any other patch open or are any other applications on the system  
growing their memory usage without bound?

I've gone through all debugging steps as suggested and it seems as though the dimmap object is the cause of the leak - Steps below.

1. Single Matrix reading from a grab object - No problem at all

2. Same original setup reading from a qt.movie into matrixset with dimmap and fade (of about 100 MB) - same issue

3. Matrixset objects replaced with single matrix object (everything else the same including fade and dimmap etc..) Same issue - if anything this take the RAM faster than any other tests so far

4. Same original setup without the Fade - Same issue

5. Same original setup without the DIMMAP - No problem

The exact issue is that MAX is taking approx. 2mb of RAM for every second that the patch is run - i've also briefly tested this on my iMac G5 (which is too big too use for the show) and am getting the same problem - although i haven't tested this as much as with my powerbook set-up (i should get to this today)

I'll play around with alternatives to the dimmap object and will post any further results.

Thanks everyone for being so helpful, i only started using Jitter last Monday and it's a real delight to fins such a helpful community here - hopefully i can return the favor in the future as i learn the software further

Hi All,
I've gone through all debugging steps as suggested and it seems as though the dimmap object is the cause of the leak - Steps below.

Setup:
10.3.9 - mac os x 667 Mhz PowerPC G4
1 GB SDRAM
MAX 4.3.1
ATY, RageM6 BUS: AGP Slot: ATI
VRAM 16 Mb

Debug Steps:
1. Single Matrix reading from a grab object - No problem at all

4. Same original setup without the Fade - Same issue 

Ok Update: I went through the same debugging steps on my iMac G5 with exactly the same result so i've now swapped the 'jit.dimmap @invert 1 0' object for a 'jit.mxform2d @offset_x -320 @boundmode 4' object and everything is running steady

Hopefully this will help anyone who hits the same problem

******fixed patch - but not completed with desired efect yet***

Hard Disk Full