gavspav

I'm journeying into the the world of the unknown with Jitter + Max for Live.

Never used Jitter before a couple of months ago and I'm barely scratching the surface now!

I'm just using it as a basic playback engine at the moment to trigger various video clips. Its working pretty well but I want to get performance as good as possible. Some background info:

- My clips are all rendered as Photo Jpeg's.

- I 'play' the quicktimes with a rate of zero and generate frame data from audio events inside Live.

- I have studied Vade's optimisation tips.

- All effects are shaders which I believe are all (?) processed on the GPU.

- All the audio is stored in wav files, handled by Live. The volume is turned down inside Jitter.

Next thing to attack is the hard drive bottleneck. I'm currently streaming movies from my hard drive which works fine unless I want to trigger movies in rapid succession one after the other. I sometimes build up rhythms with tiny fragments of a/v - this is where it falls down, usually at the beginning which is I assume when the file is being loaded.

I'm not using preroll or asyncread - not sure they are really suitable for this use and asyncread seems to cause problems for me.

I do have alot of Ram on my machine though (8GB) so should probably load all the movies into ram when I load my set.

Loadram loads movies into memory in their compressed state yes? Otherwise I will not have enough memory.

How can I load multiple movies into ram - do I need multiple jit.qt.movie objects? And maybe use poly~ to assign playback to the correct one?

- My clips are all rendered as Photo Jpeg's.
- I 'play' the quicktimes with a rate of zero and generate frame data from audio events inside Live.
- I have studied Vade's optimisation tips.
- All effects are shaders which I believe are all (?) processed on the GPU.
- All the audio is stored in wav files, handled by Live. The volume is turned down inside Jitter.

optimized-triggering-of-many-video-files

The most popular way to attack this problem is to use a poly~ - based playback system, where you load up a bunch of jit.qt.movie objects and then turn them on and off. A good, fairly solid version of this idea is included in the Video Processing System tutorials on this site. I believe Part 3 is the one where the playback module is introduced.

The most popular way to attack this problem is to use a poly~ - based playback system, where you load up a bunch of jit.qt.movie objects and then turn them on and off.  A good, fairly solid version of this idea is included in the Video Processing System tutorials on this site.  I believe Part 3 is the one where the playback module is introduced.


Thanks for that - one thing I don't get is the asyncread.

In the docs it says that it unloads any sections of the movie loaded into ram using loadram.

But loadram doesnt affect it if used afterwards?

I guess I dont really understand what asyncread does.

Also still wondering about loadram - does it decompress the video before loading it into memory or does it load it in compressed state?

Thanks for that - one thing I don't get is the asyncread.
In the docs it says that it unloads any sections of the movie loaded into ram using loadram.
But loadram doesnt affect it if used afterwards?
I guess I dont really understand what asyncread does.

Also still wondering about loadram - does it decompress the video before loading it into memory or does it load it in compressed state?


even with loadram its good practice to stick with .mov animation or photo jpeg files in my experience.

loadram loads the compressed video
even with loadram its good practice to stick with .mov animation or photo jpeg files in my experience.


Optimized triggering of many video files