Actually using "frame" not "jump", and not "frame_true".

Hi Robert,

You could try merging both vids into one file and doing something like the following (add Vade's optimizations). This should avoid the slowing framerate, but it may not work for you if audio is involved.

best, Zachary

OK...interesting. I tried a variation on this, and it DID speed it up, probably enough for me to work with it. I'll try to smooth it out a bit over the next few days, but it does seem to provide the speed I need. Thanks very much.

-Robert

I'm having the exact same problem and it's been driving me nuts trying to troubleshoot, and not making progress:

Using "jump" based on analysis of audio, to pick frames from a video file. This works GREAT until I want to have Jitter load a different video file.

Then I get amazingly sluggish performance, Jitter errors like "could not allocate matrix" and my ol' friend the spinning beach ball.

Do I have to "unload" the old movie somehow, before I can put in another one? It almost seems like the two movies are fighting. They're both the same format/approximate length.

Sorry for the incredible length of the pasted-in patch below. I've got a bit going on there. If it's impenetrable I can make a straightforward, "troubleshooting version".

As for putting these into a single movie, I'd like to avoid that-- this should ultimately be something people can drag their own clips onto.

Charlie

Hi, Hmm...when I tried to load your patch (I'm using MAX 5 on a Windows computer) I received this error: value expected in array, possible extra comma or missing "]": line=1188, char=44, text='..."hidden": 0 "midpoints": [321.5, 116.0,.'

It might be that creating a stripped-down version would be a good idea. Of course, this message might give you a hint also.

In my own code, I'm using "frame" and not "jump"...jump moves to a frame a specific distance from your start frame, and I'm moving to a specific frame number. I'm "jumping" around in the file continuously, and it moves at about 30 fps when I'm only doing this with one area of the file. However, I'm trying to make this work using two "jump" start frames and jumping targets at once, and that is slowing it way down to a few frames per second. But nothing as slow as you're reporting.

I should say that I can also load new video clips into this program, but with no new problems. I'm doing this using a standard drop-down menu, browsing to the new file and loading it., which automatically replaces the previous file without a glitch. It may slow down for a moment, but no spinning ball.

Best, Robert

might want to load all the movies at initialization time, by placing all your qt.movie stuff in one abstraction, and turning that abstraction into a poly~ object.

plenty of examples of how to do that can be found by searching "poly~ movie" or something similar.

I solved my problem. It turned out not to be an inherent speed problem...I was triggering both slab "frame" jumps with the same trigger...and (duh) getting approximatley half the speed I needed...along with some sloppy playback. I finally figured out that I could alternate the triggers before sending them to the two subroutines, and low and behold...the playback is smoothed and fast.

Life is good. Thanks for everyone's help!

Robert

Yes! Sending two QuickTime movies into a single instance of jit.qt.movie is BAD NEWS. Sorted it out... the other really important thing is to stop sending bang messages to whichever one you're not using.

This turned out to be a bit of a puzzle-- lots of bangs going all over in this patch-- but it's lead to cleaner organization overall.

Haven't yet figured out the poly~ object, but boy: be careful if you google "poly movie" to include "cycling74".

Great! Thanks for all the help, rbedgar & robtherich.