Hi all,

So I've been making a patch that plays videos using GEM, I want to play a video forwards and then play it backwards once the total number of frames is reached. The idea is to have a video that loops on repeat forwards and backwards. However, I've found that CPU rises dramatically when the video plays in reverse and everything slows down and gets jerky. I've also found a similar problem when I use [random] or [drunk] to change the frame number of the video. CPU rises dramatically and everything gets jerky. I'm also running audio at the same time but the problem persists even if audio is not playing.

I'm wondering if there's a simple solution to fixing this problem. It seems like GEM should be able to handle incoming frames that are not moving forward sequentially.

I'm running on a Macbook Pro (late 2011) with 16GB of RAM.

Any ideas/advice?

"I'm also running audio at the same time but the problem persists even if audio is not playing."

even so you might want to run separate instances of pd as suggested here.

http://forum.pdpatchrepo.info/topic/10026/syncing-issues-with-audio-video-have-searched-github-to-no-avail/4

@seed Thank you for your suggestion. Yes, this is something I have considered. However, running two separate instances of PD would require two computers, which isn't very cost effective. And as I have mentioned, the problem persist even if audio is not playing/included. This would suggest to me that there is something else going on the patch that would need to modified.

you can run a pd subprocess using the [pd~] object. take a look at the help file.

@seed Aha! I did not know this at all. Any time I've read about two or more different instances of PD being used it has always been across two separate computers. I have never even come across the [pd~] object. Thanks! I'll look into this tonight when I have time to experiment.

You can also run two processes of Pd without [pd~], but just by launching Pd twice. On a Mac this is done from the terminal.
Launch the terminal and type:
/Applications/Pd-0.47-1.app/Contents/Resources/bin/pd
Then open another terminal window and type the same thing. This should launch two separate instances of Pd.

BTW, posting the same thing twice won't really help you, especially in this forum where unread posts are being highlighted to signed in users.

@alexandros @seed, I was looking over [pd~]'s documentation last night.

Is there any preference for how which of my patches I should make into a sub-process or super-process? Or is this really an arbitrary decision that I should decide upon based on which one I'll be primarily interacting with when I'm running the patch(es)? I have two main patches at the moment - one that analyses audio and another that receives information from the audio analyses I'm running to control video playback using GEM. I'm not sure which would be better ran as a sub- or super-process. I still need to actually try implementing [pd~], so this may be something better left for me to decide. But if you have any experience regarding what way around to do things, I would appreciate your input.

Also. @alexandros my apologies for posting twice. I'm just very keen to try and these patches that I'm writing up and running. I won't double post in the future! Thank you for the advice.

Just as an update: the problem I was having wasn't CPU related in the end. The compression on the .mov files I was using was causing GEM to freak out when I tried to play the video backwards or at a random frame rate. Changing the file compression from H.264 to Apple ProRes solved this problem. I haven't experimented with other suitable compression formats yet but using ProRes seems to do the trick for now.

As a side note, using [pd~] to create a sub-process was still a great idea to do because it's freed up my CPU a lot to do more complex things in my patch(es). It just didn't solve the immediate problem I was having.

The best codec for me with a similar setup is AppleIntermediate performance wise.

@Johnny-Mauser Thanks for the suggestion, I'll check it out!