Forums > MaxMSP

Standalone a cpu hog?

January 17, 2012 | 12:43 am

Hello there.

I’ve finished a project recently and made a standalone app.

But I have noticed that the standalone reaches its limit (Thread maxed out on the cpu, fps drop) much quicker than if I run the same patch from within Max5 itself.

Especially playing back movies seems to consume much more cpu with the standalone.

Are there any tips/tricks I’ve missed? Or is that just how it is?
I’ve read that some people experience rather the opposite..?
It would be unfortunate if the client has to buy a full max version just to run the patch as efficient as possible.

I appreciate your thoughts on this,

Simon


July 3, 2012 | 6:40 pm

hi
so… did u find a solution?
i’m experiencing the same problem here
bests
ido


July 4, 2012 | 9:20 am

I am not aware of any obvious reason why a standalone should use significantly more resources than the base patch running in Max. And I can’t say I’ve ever seen this in building collectives and standalones. Which doesn’t mean it can’t happen.

You’ll need to analyze your patch to see where the bottle-necks may be. If you can build a reasonably compact version of your patch that demonstrates the issue, then by all means post it. I know it can be a lot of work to trim down a patch to just the core of the problem, but without that, everyone else can only guess in the dark. Sorry.


July 5, 2012 | 7:22 am

peter,
trimming the patch is a crazy thing to do indeed right now… :)
I can for sure approve that there’s a huge difference between the patch and standalone but I don’t know why.
but, here’s a "solution" to (at least) my problem: it turns out, that if you want to load one video file after the other, and the 2nd video file is large, almost 1G, it somehow "stuck" the patch because of the slow load into the jit.qt object – this result, i suspect, in few bangs that wasn’t initialized properly and so the patch behaved not normal.
To solve this, I simply sent a dispose message to jit.qt and then load the 2nd video file to an "empty" jit.qt…
Again, it might be my "fault", I have to analyze this further, but this process solved the problem for now.
bests, ido


Viewing 4 posts - 1 through 4 (of 4 total)