Hi, I had some problems with metro running irregular. Im on osx 10.3.9. I was running Pd-0.38-2hcs0 installer. Cause of the problems I went to Hans Christoph's site to see if there was any updates. I downloaded the recent installer Pd-0.38-4-extended-RC1 and the experimental Pd-0.39test2-extended-RC0.
My patch uses Gem (5x curve3d 3 3) and 4 midi notes routed to Reason. The results was very interesting. On the latest installer the metro was running fine but the performance was incredibly slow. I could not edit anything while running. It looks like all the pipes got completely blocked. The experimental installer was a bit faster, but not by much.
The patch was using about 90 percent cpu on the latest installer, 75 on the experimental and 60 on the old.
Ive gone back to the old and the metro seems back on track.
Is there a reason for this? Thought I should mention it.
Timon.
What versions of Gem are you running?
If the whole OS becomes unresponsive yet GEM still cranks out the pixels and vertices then that is a sure sign of the pthread scheduling hack being on. I thought that was only invoked with the -rt flag on OSX, but maybe that has reverted back.
The curve3d object has some quirks apparently (reported on gem-dev today) and it is certainly not easy on the CPU. If one version you tested was missing some metro driven events and the other got them all, there would be a difference in CPU load.
I don't use any of the installers so I can't really help reproduce the issue. The best tool to use on OSX for diagnosing performance issues is an app called Shark. You need the developer tools, perhaps a CHUD installer and more than a passing knowledge of the PowerPC architecture to really make sense of it. If you manage to record profiles of each version with Shark then we could probably pin down the problem very quickly and surely. I strongly encourage the more experienced OSX Pd/GEM users learn how to use this app as it can pinpoint bottlenecks in you patches without fail.
cgc
On Jul 19, 2005, at 4:34 PM, timon botez wrote:
Hi, I had some problems with metro running irregular. Im on osx 10.3.9. I was running Pd-0.38-2hcs0 installer. Cause of the problems I went to Hans Christoph's site to see if there was any updates. I downloaded the recent installer Pd-0.38-4-extended-RC1 and the experimental Pd-0.39test2-extended-RC0.
My patch uses Gem (5x curve3d 3 3) and 4 midi notes routed to Reason. The results was very interesting. On the latest installer the metro was running fine but the performance was incredibly slow. I could not edit anything while running. It looks like all the pipes got completely blocked. The experimental installer was a bit faster, but not by much.
The patch was using about 90 percent cpu on the latest installer, 75 on the experimental and 60 on the old.
Ive gone back to the old and the metro seems back on track.
Is there a reason for this? Thought I should mention it.
Timon.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I was using the version bundled with the installer. It looks like its the same version on all 3 installers that I used. If you have any pointers to where I can get the OSX diagnostics software I would be grateful.
Any word on the dual monitor issue?
Thanks, T.
GEM: Graphics Environment for Multimedia GEM: ver: 0.90 GEM: compiled: Apr 13 2005 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version on irix/windows) GEM: Chris Clepper (macOS-X) GEM: Daniel Heckenberg (windows) GEM: James Tittle (macOS-X) GEM: IOhannes m zmoelnig (linux/windows) On 20 Jul 2005, at 02:28, chris clepper wrote:
What versions of Gem are you running?
If the whole OS becomes unresponsive yet GEM still cranks out the pixels and vertices then that is a sure sign of the pthread scheduling hack being on. I thought that was only invoked with the -rt flag on OSX, but maybe that has reverted back.
The curve3d object has some quirks apparently (reported on gem-dev today) and it is certainly not easy on the CPU. If one version you tested was missing some metro driven events and the other got them all, there would be a difference in CPU load.
I don't use any of the installers so I can't really help reproduce the issue. The best tool to use on OSX for diagnosing performance issues is an app called Shark. You need the developer tools, perhaps a CHUD installer and more than a passing knowledge of the PowerPC architecture to really make sense of it. If you manage to record profiles of each version with Shark then we could probably pin down the problem very quickly and surely. I strongly encourage the more experienced OSX Pd/GEM users learn how to use this app as it can pinpoint bottlenecks in you patches without fail.
cgc
On Jul 19, 2005, at 4:34 PM, timon botez wrote:
Hi, I had some problems with metro running irregular. Im on osx 10.3.9. I was running Pd-0.38-2hcs0 installer. Cause of the problems I went to Hans Christoph's site to see if there was any updates. I downloaded the recent installer Pd-0.38-4-extended-RC1 and the experimental Pd-0.39test2-extended-RC0.
My patch uses Gem (5x curve3d 3 3) and 4 midi notes routed to Reason. The results was very interesting. On the latest installer the metro was running fine but the performance was incredibly slow. I could not edit anything while running. It looks like all the pipes got completely blocked. The experimental installer was a bit faster, but not by much.
The patch was using about 90 percent cpu on the latest installer, 75 on the experimental and 60 on the old.
Ive gone back to the old and the metro seems back on track.
Is there a reason for this? Thought I should mention it.
Timon.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
chris clepper -
timon botez