Thijs Koerselman

I am using Randy Jones his render_node patch to render some video's. It

switches max to non-realtime to render every frame. The problem is

max/jitter takes a very long time to render things that it can do in

realtime. I have a jitter patch running at about 60% cpu usage in realtime.

When I start recording it, it records at about 1 fps. The example patch that

comes with render_node is showing the same behavior.

The weird thing is that max itself shows 100% cpu usage, while my

taskmanager shows its doing almost nothing. The max interface is jammed

like it would be at 100%, but I can keep on using other programs without

problems. My computer even turns on its screensaver after a while, and it

I stripped down the patch to where its basically only rendercontext ->

to_texture -> jit.qt.record, bypassing the frame accumulations and plugins,

but without luck. Also the movie size and codec doesn't make much of a

difference. Rendering 320x240 raw against 800x600 jpeg, still about 1fps.

I also tried changing the dsp settings. As far as I know Randy doesn't know

what's up either, and I suppose its the same on mac as it is on my windows

system. I'm wondering if someone can tell me something relevant about this

realtime mode. Am I missing something? Does anyone have similar experience

I recently had to wait for 3 hours to render a 4,5min movie :-/

I am using Randy Jones his render_node patch to render some video's. It
switches max to non-realtime to render every frame. The problem is
max/jitter takes a very long time to render things that it can do in
realtime. I have a jitter patch running at about 60% cpu usage in realtime.
When I start recording it, it records at about 1 fps. The example patch that
comes with render_node is showing the same behavior.

The weird thing is that max itself shows 100% cpu usage, while my
taskmanager shows its doing almost nothing. The max interface is jammed
like it would be at 100%, but I can keep on using other programs without
problems. My computer even turns on its screensaver after a while, and it
doesn't interfere with anything.

I stripped down the patch to where its basically only rendercontext ->
to_texture -> jit.qt.record, bypassing the frame accumulations and plugins,
but without luck. Also the movie size and codec doesn't make much of a
difference. Rendering 320x240 raw against 800x600 jpeg, still about 1fps.

I also tried changing the dsp settings. As far as I know Randy doesn't know
what's up either, and I suppose its the same on mac as it is on my windows
system. I'm wondering if someone can tell me something relevant about this
realtime mode. Am I missing something? Does anyone have similar experience
with non-realtime mode?

non-realtime-cpu-issues-using-render_node

On Mar 30, 2006, at 12:52 PM, Thijs Koerselman wrote:

> I also tried changing the dsp settings. As far as I know Randy 

> doesn't know what's up either, and I suppose its the same on mac as 

> it is on my windows system. I'm wondering if someone can tell me 

> something relevant about this realtime mode. Am I missing 

> something? Does anyone have similar experience with non-realtime mode?

Well sfplay~ and sfrecord in NRT mode perform synchronous disk access 

and are *quite* slow as a result. NRT mode is primarily in place for 

us to debug MSP objects, and though it is useful for tasks like this, 

it doesn't warrant the considerable oevrhaul that would be necessary 

to speed up sfplay~ and sfrecord~ in this case. The work around is to 

record into a buffer~ with record~ and then export the buffer~ to 

AIFF at the final stage. I guarantee that this will be noticably 

faster than using sfplay~/sfrecord~ in NRT mode (and I believe this 

is floating around the maxmsp mailing list archives somewhere.

I have a hunch that this is where your bottleneck lies, but if not, 

keep stripping your patch down, disabling MSP and DSP in NRT, etc. 

until you come to a conclusion as to where the precise bottleneck 

lies. Shark (part of Apple's excellent CHUD tools, downloadable from 

their developer site) may prove useful for determining what is taking 

the performance hit, though it can be misleading in situations where 

MaxMSP is spending all it's time waiting on synchronous disk I/O (and 

thus not showing up much in the process monitor or in shark).

> I also tried changing the dsp settings. As far as I know Randy  
> doesn't know what's up either, and I suppose its the same on mac as  
> it is on my windows system. I'm wondering if someone can tell me  
> something relevant about this realtime mode. Am I missing  
> something? Does anyone have similar experience with non-realtime mode?

Well sfplay~ and sfrecord in NRT mode perform synchronous disk access  
and are *quite* slow as a result. NRT mode is primarily in place for  
us to debug MSP objects, and though it is useful for tasks like this,  
it doesn't warrant the considerable oevrhaul that would be necessary  
to speed up sfplay~ and sfrecord~ in this case. The work around is to  
record into a buffer~ with record~ and then export the buffer~ to  
AIFF at the final stage. I guarantee that this will be noticably  
faster than using sfplay~/sfrecord~ in NRT mode (and I believe this  
is floating around the maxmsp mailing list archives somewhere.

I have a hunch that this is where your bottleneck lies, but if not,  
keep stripping your patch down, disabling MSP and DSP in NRT, etc.  
until you come to a conclusion as to where the precise bottleneck  
lies. Shark (part of Apple's excellent CHUD tools, downloadable from  
their developer site) may prove useful for determining what is taking  
the performance hit, though it can be misleading in situations where  
MaxMSP is spending all it's time waiting on synchronous disk I/O (and  
thus not showing up much in the process monitor or in shark).

On Mar 30, 2006, at 3:52 PM, Thijs Koerselman wrote:

> I recently had to wait for 3 hours to render a 4,5min movie :-/

while i haven't had time to check out render_node yet ,this is not

unusual for off-line rendering in general. a lot of my work entails

the use of high end compositing programs like after effects where

several seconds of hi-rez video can take hours.

"Reality is whatever refuses to go away when I stop believing in it.."

while i haven't had time to check out render_node yet ,this is not
unusual for off-line rendering in general. a lot of my work entails
the use of high end compositing programs like after effects where
several seconds of hi-rez video can take hours.
cheers
bruce

"Reality is whatever refuses to go away when I stop believing in it.."
Philip K. Dick

Thanks!! I just deleted the audio recording part, and it's rendering in

realtime speed now :-) x30 speed up! Awesome. I read about this in the

archives just after posting my mail... stupid me.

Thanks!! I just deleted the audio recording part, and it's rendering in
realtime speed now :-) x30 speed up! Awesome. I read about this in the
archives just after posting my mail... stupid me.

M/M/J has not yet been released for the new Intel Macs.

--
***
http://danwinckler.com
http://share.dj
http://gunshowimprov.com


non-realtime cpu issues (using render_node)