Perhaps we could add in a preference which would renice the gui or core
process to a lower priority. That would not require any special
permissions, like setuid. And it could be reset with a reset. Perhaps
even a message to pd to set it, so that a give patch can set things
that way. I wonder if that would be worth it, or whether there is a
better approach (probably).
.hc
On Feb 20, 2006, at 10:20 AM, day 5 wrote:
Well, I only increase the priority of the pd background process when
I'm doing realtime audio and video simultaneously.I imagine for users that are dealing with really intense graphic
interfaces, you can simply instead increase processing priority to the
Pd.app instead of the pd background process.It seems to work anyway, i'd imagine a
% renice -20 -p[pd process id here]
would work just as well. In any event, using these techniques of
manipulating processing priority lets users get a LOT more mileage out
of the pd-extended builds than you would normally get when all
nicelevel = 0../d5
On Feb 20, 2006, at 12:42 AM, Hans-Christoph Steiner wrote:
What do you do exactly? Increase the priority of the pd background
process?It sounds like we need to revisit the "realtime" priority stuff on
Mac OS X. Sara, have you tried using the -nrt flag with a newer
version of Pd? I am curious as to whether that would make a
difference..hc
On Feb 19, 2006, at 9:07 PM, day 5 wrote:
Hi Sara (and others reading this thread),
have you tried this on OS X ?
http://www.lachoseinteractive.net/en/products/processwizard/
It's basically just a frontend for the unix renice command. I find
that it's possible to get 25-30% increase in efficiency using this.You can choose to increase the CPU processing priority of either the
GUI or the audio/video. whatever you see fit. Possibly this can
serve as an interim solution../d5
On Feb 19, 2006, at 8:59 PM, sara kolster wrote:
Hi Hans,
Hans-Christoph Steiner wrote: I was well aware of the slowness of the Pd GUI on Mac OS X, but
its news to me that its actually slower than older versions. That
would be very good to test. Tigital did a bunch of work
streamlining the Tk/Aqua stuff to use CoreGraphics, which should
speed things up quite a bit. I am wondering what makes things go
slower with newer versions.I am still using the 0.37.1 PD-version(on osx.3.9) for the exact
same reason that the newer versions of pd are super slow. Opening
up my performance interface (using quite a few abstractions) and
trying to push a toggle or bang is nearly impossible. No response
at all.As you, I am puzzled by the fact what changed in the newer versions
which makes the pd-GUI slower than the older versions. I'm using
the 0.37.1 version without X11 and i'm using the tcl/tk 8.4.9 (wish
shell). I'm not a great fan of using X11, but if that would help
figuring out what went different in the production of the newer
pd-versions, than that would be worth trying.Sara
One thing that tigital is proposing, which I think would be worth
trying, is making a Fink/X11 version of Pd. This should get
around the slowness of Tk/Aqua, but would mean that you need X11
to use that version of Pd..hc
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
"Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism." - retired U.S. Army general,
William Odom
¡El pueblo unido jamás será vencido!