jason@seeinginvideo.com

I've been trying to work with a remixed version of Andrew Benson's VPS 4 patch and i've been running into issues with loading a large database of clips into the patch. All of the clips are 720p compressed as Photo-JPEG, being run off of an 3ghz 8 core mac with 4 gigs of ram, OS 10.5.8.

Once I load more than 40 clips from a folder, by the time the clips are almost all loaded, max crashes and a still from the clip fills the screen. I have mixed in elements from Vade's optimization examples as well as changing asyncread to read.

Ideally, I would like to have a database of around 450 clips ranging from 4-12 seconds long a piece to work with for this project I am undertaking. My guess is that the loadram poly~ method will probably not work well for this. Is there any other way to have a clean cut from clip to clip like what is seen in AB's patch, or am I asking too much of the system?

Hi,
   I've been trying to work with a remixed version of Andrew Benson's VPS 4 patch and i've been running into issues with loading a large database of clips into the patch. All of the clips are 720p compressed as Photo-JPEG, being run off of an 3ghz 8 core mac with 4 gigs of ram, OS 10.5.8. 

Once I load more than 40 clips from a folder, by the time the clips are almost all loaded, max crashes and a still from the clip fills the screen. I have mixed in elements from Vade's optimization examples as well as changing asyncread to read. 

Ideally, I would like to have a database of around 450 clips ranging from 4-12 seconds long a piece to work with for this project I am undertaking. My guess is that the loadram poly~ method will probably not work well for this. Is there any other way to have a clean cut from clip to clip like what is seen in AB's patch, or am I asking too much of the system?


more-issues-with-hd-database-patch-working-with-vps-4

Instead of using loadram, you could potentially make a RAM disk. Basically it sounds like you are running out of memory, exceeding the limitations of 32 bit memory space. Here's a thread which shows how to use the command line disk utility. There might be other third party RAM disk solutions. I'm not sure.

https://cycling74.com/forums/workaround-for-ram-limit

The 'loadram' portion of the movie-loader is intended to just load the beginning and end of each video into RAM to make initial triggering and looping faster. You might try making that chunk smaller, by altering the poly~ subpatch, and see if that looks better.

I did make smaller amounts of ram to load *down to 400ms* in the poly~ subpatch, but it did eventually overload the system and crashed it again.

Andrew
I did make smaller amounts of ram to load *down to 400ms* in the poly~ subpatch, but it did eventually overload the system and crashed it again.

Josh
Thanks for the tip, i'll try that out!


Ok, last question on this. In the past when I have needed a database of movies that need to self populate, I use this method of routing out movie info and have the change occur when the movie gets to the end of its timecode:

With the jit.qt.movie object inside of the poly object, I found that it was not routing out this information. I'm not sure why, I have messages that are being triggered for gettime, getduration etc., but alas it might show the time or duration for the first clip, but when a new one is chosen through the vps4 umenu it does not update. Is there a work around or a better way to get a bang out at the end of a clip with the vps4 system? Thanks

i don't want to seem rude, but this problem is driving me crazy.....bump?

My workaround was to use a [coll] object with the durations of all my quicktimes listed inside. I used the 'item number' output of the [umenu] to recall them and put them into the ranges of different slider objects. It's not dynamic, but at least you scrub and select looppoints on the fly.

More issues with HD database patch / working with VPS 4