Hello,
I don't know if this is a documented set of problems or not:
I have tested this on both ppc and intel machines running OSX (10.4 only, and most extensively on intel). Running "top" in a terminal or looking at the OSX activity monitor, it looks like both Pd vanilla (0.41) and extended (0.39 -- I haven't yet tested any new autobuilds) run two processes -- in vanilla, the names of the processes are pd and Pd, and in extended they are pd and Pd-extended.
If I am having PD run through coreaudio, either built-in or through a firewire interface, the cpu usage jumps to a consistently high 25% to 50% just by clicking "compute audio." It's accounted for in the pd cpu loadmeter, and for both vanilla and extended it's the "pd" process that shows the corresponding cpu usage in "top." It goes back down to between 0% and 5% when I stop audio.
Then, if I connect to jack (using jackpilot), computing audio shows no huge jump in cpu, so that problem disappears.
The other problem is that any vu meters connected to [env~] -- even running at 16384 -- will make the "Pd" or "Pd-extended" processes (not the "pd" process as before) jump to between 15% and 30%, but the corresponding jump does not show up in pd's cpu loadmeter. I haven't seen this problem in linux or windows unless I'm running the env~ very fast (and surprisingly it seems to be more efficient in windows?).... it wouldn't bother me so much, but I'm traveling soon and I have to use OSX in a concert.
Is all of this normal? I've talked to other mac users and they have seen the same issues.
Thanks,
Matt
Hi Matt,
both problems are well known. On OSX, the Coreaudio interface is quite CPU hungry. Using Jack is recommended. Myself and others have posted several times about this.
And as far as the GUI goes, I've been bringing this issue up for years now. You can check the archives yourself and see. In short, PD's GUI is slower on OSX than any other OS. The solutions which are often suggested to me when I complain about this are a) use less GUI objects, b) become a developer and fix it yourself and c) use Linux. I chose the last, and found that my patches ran 50% better using Linux on the same Powerbook.
best, d.
Matt Barber wrote:
If I am having PD run through coreaudio, either built-in or through a firewire interface, the cpu usage jumps to a consistently high 25% to 50% just by clicking "compute audio."
Then, if I connect to jack (using jackpilot), computing audio shows no huge jump in cpu, so that problem disappears.
The other problem is that any vu meters connected to [env~] -- even running at 16384 -- will make the "Pd" or "Pd-extended" processes (not the "pd" process as before) jump to between 15% and 30%, but the corresponding jump does not show up in pd's cpu loadmeter.
For the next Pd-extended release, it'll use Tcl/Tk 8.5, which
includes a lot of work done on the Mac OS X graphics side of things.
That should make things faster.
.hc
On May 27, 2008, at 9:24 AM, Derek Holzer wrote:
Hi Matt,
both problems are well known. On OSX, the Coreaudio interface is quite CPU hungry. Using Jack is recommended. Myself and others have posted several times about this.
And as far as the GUI goes, I've been bringing this issue up for years now. You can check the archives yourself and see. In short, PD's
GUI is slower on OSX than any other OS. The solutions which are often
suggested to me when I complain about this are a) use less GUI objects, b)
become a developer and fix it yourself and c) use Linux. I chose the last,
and found that my patches ran 50% better using Linux on the same
Powerbook.best, d.
Matt Barber wrote:
If I am having PD run through coreaudio, either built-in or through a firewire interface, the cpu usage jumps to a consistently high 25% to 50% just by clicking "compute audio."
Then, if I connect to jack (using jackpilot), computing audio
shows no huge jump in cpu, so that problem disappears.The other problem is that any vu meters connected to [env~] -- even running at 16384 -- will make the "Pd" or "Pd-extended" processes
(not the "pd" process as before) jump to between 15% and 30%, but the corresponding jump does not show up in pd's cpu loadmeter.-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 36: "Consult other sources -promising -unpromising"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
I'm excited to try it out!
~Kyle
On Tue, May 27, 2008 at 4:30 AM, Hans-Christoph Steiner hans@eds.org wrote:
For the next Pd-extended release, it'll use Tcl/Tk 8.5, which includes a lot of work done on the Mac OS X graphics side of things. That should make things faster.
.hc
On May 27, 2008, at 9:24 AM, Derek Holzer wrote:
Hi Matt,
both problems are well known. On OSX, the Coreaudio interface is quite CPU hungry. Using Jack is recommended. Myself and others have posted several times about this.
And as far as the GUI goes, I've been bringing this issue up for years now. You can check the archives yourself and see. In short, PD's GUI is slower on OSX than any other OS. The solutions which are often suggested to me when I complain about this are a) use less GUI objects, b) become a developer and fix it yourself and c) use Linux. I chose the last, and found that my patches ran 50% better using Linux on the same Powerbook.
best, d.
Matt Barber wrote:
If I am having PD run through coreaudio, either built-in or through a firewire interface, the cpu usage jumps to a consistently high 25% to 50% just by clicking "compute audio."
Then, if I connect to jack (using jackpilot), computing audio shows no huge jump in cpu, so that problem disappears.
The other problem is that any vu meters connected to [env~] -- even running at 16384 -- will make the "Pd" or "Pd-extended" processes (not the "pd" process as before) jump to between 15% and 30%, but the corresponding jump does not show up in pd's cpu loadmeter.
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 36: "Consult other sources -promising -unpromising"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If anyone wants to try to beat me to the punch and make their own Tcl
8.5 builds, please do! I'll help where I can.
On May 28, 2008, at 6:44 PM, Kyle Klipowicz wrote:
I'm excited to try it out!
~Kyle
On Tue, May 27, 2008 at 4:30 AM, Hans-Christoph Steiner
hans@eds.org wrote:For the next Pd-extended release, it'll use Tcl/Tk 8.5, which includes a lot of work done on the Mac OS X graphics side of things. That should make things faster.
.hc
On May 27, 2008, at 9:24 AM, Derek Holzer wrote:
Hi Matt,
both problems are well known. On OSX, the Coreaudio interface is
quite
CPU hungry. Using Jack is recommended. Myself and others have posted several times about this.
And as far as the GUI goes, I've been bringing this issue up for
years
now. You can check the archives yourself and see. In short, PD's GUI is slower on OSX than any other OS. The solutions which are often suggested to me when I complain about this are a) use less GUI objects, b) become a developer and fix it yourself and c) use Linux. I chose the last, and found that my patches ran 50% better using Linux on the same Powerbook.
best, d.
Matt Barber wrote:
If I am having PD run through coreaudio, either built-in or
through a
firewire interface, the cpu usage jumps to a consistently high
25% to
50% just by clicking "compute audio."
Then, if I connect to jack (using jackpilot), computing audio shows no huge jump in cpu, so that problem disappears.
The other problem is that any vu meters connected to [env~] -- even running at 16384 -- will make the "Pd" or "Pd-extended" processes (not the "pd" process as before) jump to between 15% and 30%, but the corresponding jump does not show up in pd's cpu loadmeter.
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 36: "Consult other sources -promising -unpromising"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
--
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz
Access to computers should be unlimited and total. - the hacker ethic
Yep, me too ! Thanx Hans. ++
Jack
Le 28 mai 08 à 18:44, Kyle Klipowicz a écrit :
I'm excited to try it out!
~Kyle
On Tue, May 27, 2008 at 4:30 AM, Hans-Christoph Steiner
hans@eds.org wrote:For the next Pd-extended release, it'll use Tcl/Tk 8.5, which includes a lot of work done on the Mac OS X graphics side of things. That should make things faster.
.hc
On May 27, 2008, at 9:24 AM, Derek Holzer wrote:
Hi Matt,
both problems are well known. On OSX, the Coreaudio interface is
quite
CPU hungry. Using Jack is recommended. Myself and others have posted several times about this.
And as far as the GUI goes, I've been bringing this issue up for
years
now. You can check the archives yourself and see. In short, PD's GUI is slower on OSX than any other OS. The solutions which are often suggested to me when I complain about this are a) use less GUI objects, b) become a developer and fix it yourself and c) use Linux. I chose the last, and found that my patches ran 50% better using Linux on the same Powerbook.
best, d.
Matt Barber wrote:
If I am having PD run through coreaudio, either built-in or
through a
firewire interface, the cpu usage jumps to a consistently high
25% to
50% just by clicking "compute audio."
Then, if I connect to jack (using jackpilot), computing audio shows no huge jump in cpu, so that problem disappears.
The other problem is that any vu meters connected to [env~] -- even running at 16384 -- will make the "Pd" or "Pd-extended" processes (not the "pd" process as before) jump to between 15% and 30%, but the corresponding jump does not show up in pd's cpu loadmeter.
-- derek holzer ::: http://www.umatic.nl ::: http://blog.myspace.com/ macumbista ---Oblique Strategy # 36: "Consult other sources -promising -unpromising"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
--
"It is convenient to imagine a power beyond us because that means we don't have to examine our own lives.", from "The Idols of Environmentalism", by Curtis White
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
--
http://perhapsidid.wordpress.com http://myspace.com/kyleklipowicz _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
-
Derek Holzer -
Hans-Christoph Steiner -
Jack -
Kyle Klipowicz -
Matt Barber