Looking at your last (private) message:
The audio doesn't stall per se, it's more like values aren't getting updated consistantly so say a pitch sweep will "jump" along with the numerical input.
... it's sounding more and more like the real-time issue that Miller pointed out. A pitch sweep shouldn't be interrupted like that, in my experience, unless you have some other processor-greedy apps running at the same time.
However, the performance of Aqua Tcl/Tk doesn't help things, either. Controls like number boxes cause a bunch of screen-redraw interrupts that are themselves greedy. Part of it is apparently AquaTk canvasses still use QuickDraw.
Still, the stated specs on your machine should be able to run PD fairly well, as long as you minimize the screen updates on patches where you demand good audio performance.
And I agree, jMax 4.0 has a very attractive, seductive screen interface. Pity it crashed the first time I tried to turn on DSP. :-/
I think there's a lot still to be optimized in the MacOSX port, though, both in user experience and in performance. Chris Clepper wrote recently about compiling with different optimization settings. Might be worth a bit of experimentation...
adam
Ryan Gallagher said this at Tue, 12 Nov 2002 08:42:00 -0800:
Hmm...
So it's a Tcl/Tk thing, or a getting Tcl/Tk to work well with Pd thing?
Honestly at this point I'd rather use Pd (more active community, developed well and often, seems a bit more avant guard, etc.) but I'm really only interested in real-time tweaking... If there's a chance things could improve I'll pursue Pd but if that's just the way Tcl/Tk is on OS X I'll go with jMax also.
Is Tcl slow on the linux platform? Early jMax and early Pd were both dog slow on my linux PII 200 last yearish...
JMax has a nice interface (java anti-aliasing etc.) and it's actually being developed pretty intensly. 4.0.0 is looking good.
thanks Adam, Miller et.al, -ryan
--- Adam Lindsay atl@comp.lancs.ac.uk wrote:
Okay, if you're running such a recent Tcl/Tk, it's not the bug I was alluding to, and more like what Miller mentioned. The current Tcl/Tk's are hard to work with because the screen interrupts can cause skips in the sound buffers.
It does run pretty well if you do *not* rely on live updating numberboxes and the like. You can always increase the buffer size by one notch, too.
I've just downloaded jMax, but I haven't had a chance to test it. It sure looks a lot prettier, though. Sigh.
adam
I believe Ryan Gallagher said this around Mon, 11 Nov 2002:
Hi,
Thanks for that tip.
I am using 8.4.1 just compiled last week. The
audio
doesn't stall per se, it's more like values aren't getting updated consistantly so say a pitch sweep
will
"jump" along with the numerical input.
A friend told me Pd on osx runs better than jMax. This hasn't been my experience at all so I thought
I'd
get some feedback from other pd osx users.
thanks again, ryan
--- Adam Lindsay atl@comp.lancs.ac.uk wrote:
If you're running Jaguar and are experiencing a stalled graphical interface, do make sure you're running the latest (8.4.1) Tcl/Tk. The most recent builds at Sourceforge are nice
looking
(antialiased text... which may not help performance). Mac OSX 10.2 introduced some issues with older versions of Tcl/Tk which have subsequently been fixed.
http://prdownloads.sourceforge.net/tcl/TclTkAqua-8.4.1-Jaguar.dmg?download
Stalled audio input is another matter. I have an iMac with similar specs, and it's tricky to get good performance.
Best of luck, adam
I believe Ryan Gallagher said this around Mon, 11 Nov 2002:
Hi there,
I read that Pd is "(somewhat shakily) running on Macintosh OS/X" and decided to give er a try...
I
was
wondering if one of the "shakes" is jumpy
unresponsive
mouse input? When clickin on a number object
and
moving the mouse up and down, there appears to
be
certain freezing and skipping in the interface
(also
observable in audio output).
Is this the state of affairs or do I have
something
mis-configured, I have a G3 400, 512mb ram,
OSX.2.1.
thanks, ryan
Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
PD-dev mailing list PD-dev@iem.kug.ac.at
http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Adam Lindsay +44(0)1524 594 537 atl@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
===== -r-
Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
--
Adam Lindsay +44(0)1524 594 537 atl@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
===== -r-
Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
Looking at your last (private) message:
The audio doesn't stall per se, it's more like values aren't getting updated consistantly so say a pitch sweep will "jump" along with the numerical input.
... it's sounding more and more like the real-time issue that Miller pointed out. A pitch sweep shouldn't be interrupted like that, in my experience, unless you have some other processor-greedy apps running at the same time.
renice -20 helps some, but even with the most basic patch and no other processes running it will still drop samples. the gui shouldn't affect the audio at all with this setting. also moving or changing gui elements in apps other than pd/wish will cause the dropout clicks as well. looking at pd in the debugger, it looks like audio runs in it's own thread. is this correct?
However, the performance of Aqua Tcl/Tk doesn't help things, either. Controls like number boxes cause a bunch of screen-redraw interrupts that are themselves greedy. Part of it is apparently AquaTk canvasses still use QuickDraw.
quickdraw should be ok as long as they don't pile on the CopyBits which has become dog slow in OSX due to the double buffering. i wonder how many buffers each graphic object has using the wish shell? one for tcl/wish + 2 for quartz?
Still, the stated specs on your machine should be able to run PD fairly well, as long as you minimize the screen updates on patches where you demand good audio performance.
pd runs quite well on the same machine (g3/400) running linux. since core-audio is well integrated into the OSX kernel, i would expect the performance to be on par or better than linux. in fact i'm getting very low latency (<8ms) and good performance in other OSX audio apps on the same box. can others contribute pd performance info on other macs? pd runs fine on a dual 1ghz box, but what about older boxes?
I think there's a lot still to be optimized in the MacOSX port, though, both in user experience and in performance. Chris Clepper wrote recently about compiling with different optimization settings. Might be worth a bit of experimentation...
the -03 compiler setting gave slightly better performance but nothing truly remarkable. if i recall one of the main differences between gcc -02 and -03 was the unrolling of loops??
cgc
Hey PDers,
With all these discussions about performance, I was wondering if anyone has played around with "reference" patches that could be used for the sake of profiling. Would that be a useful thing, to come up with a patch or a suite of patches that give PD a general, typical (if there could possibly be such a thing) workout?
I believe chris clepper said this around Tue, 12 Nov 2002:
However, the performance of Aqua Tcl/Tk doesn't help things, either. Controls like number boxes cause a bunch of screen-redraw interrupts that are themselves greedy. Part of it is apparently AquaTk canvasses still use QuickDraw.
quickdraw should be ok as long as they don't pile on the CopyBits which has become dog slow in OSX due to the double buffering. i wonder how many buffers each graphic object has using the wish shell? one for tcl/wish + 2 for quartz?
Errr, I honestly couldn't tell you. Some time asking on the Tcl-Mac list tcl-mac@lists.sourceforge.net would probably get you somewhere. They're a helpful bunch.
I think there's a lot still to be optimized in the MacOSX port, though, both in user experience and in performance. Chris Clepper wrote recently about compiling with different optimization settings. Might be worth a bit of experimentation...
the -03 compiler setting gave slightly better performance but nothing truly remarkable. if i recall one of the main differences between gcc -02 and -03 was the unrolling of loops??
That's about the size of it, as -O2 does optimizations where there isn't a size-speed tradeoff, and -O3 does. I've noticed some places where Miller has hand-unrolled stuff in the code, anyway.
Cheers, adam
--
Adam Lindsay +44(0)1524 594 537 atl@comp.lancs.ac.uk http://www.comp.lancs.ac.uk/computing/users/atl/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Hey PDers,
With all these discussions about performance, I was wondering if anyone has played around with "reference" patches that could be used for the sake of profiling. Would that be a useful thing, to come up with a patch or a suite of patches that give PD a general, typical (if there could possibly be such a thing) workout?
good idea. how about starting with the 'Test audio and MIDI' patch that comes with PD? that's been my profiling patch so far. there was a 'spinning' number box patch floating around some time ago that tested the gui performance.
cgc
On Tue, 12 Nov 2002, Adam Lindsay wrote:
With all these discussions about performance, I was wondering if anyone has played around with "reference" patches that could be used for the sake of profiling. Would that be a useful thing, to come up with a patch or a suite of patches that give PD a general, typical (if there could possibly be such a thing) workout?
I'd like to say that GridFlow 0.4-0.5 has a runtime profiler that almost does not affect performance and is quite accurate.
I don't know how adding such a feature directly to PD/jMax would influence performance, though; what works especially well with GridFlow is that most methods, on average, take a long time to run; they typically do between ten and a thousand math operations before passing control to the next method.
In GridFlow 0.6 I removed the profiler but I think it's temporary and I will find out how to integrate a new profiler with the new gridflow in a proper manner.
When I say runtime profiler, I mean that you can consult its results at runtime and reset it and you can find which _objects_ are doing the most work and a regular PD user can take advantage of it to know where the bottleneck is (however it's true that fixing the bottlenecks is actually more difficult).
Regular profiling (with gprof and profiler.rb and such) might be interesting, but for different reasons, mostly for core/external writers.
That's about the size of it, as -O2 does optimizations where there isn't a size-speed tradeoff, and -O3 does. I've noticed some places where Miller has hand-unrolled stuff in the code, anyway.
I hand-unrolled stuff in my code too; gcc, or at least some common versions thereof, can't figure out some unrollings, especially with variable number of iterations; what i do is I transform this:
while (n) {
do_stuff_here;
n--;
}
into:
while (n&3) {
do_stuff_here;
n--;
}
while (n) {
do_stuff_here;
do_stuff_here;
do_stuff_here;
do_stuff_here;
n-=4;
}
which is the fastest i could do without bloating the codesize too much.
Mathieu Bouchard http://artengine.ca/matju
-
Adam Lindsay -
Adam T. Lindsay
-
chris clepper -
Mathieu Bouchard