I've been running pd on my slow wearable (500Mhz) and, over the last year, the performance has gotten worse. This trend coincides with my greater understanding of pd and adoption of nice GOP guis.
So basically, all of the work I have done to make an easy to use environment for making songs/patches is practically worthless as the GOP/gui stuff kills the cpu on the wearable. Nobody seems to care as we all have exponentially faster computers each day, which is too bad as one of pd's strengths in my opinion is it's ability to run on basically anything.
I'm just wondering if there are others with slow cpu (iPhone RJDJ) machines and how their approach to patching deals with this issue.
Basically, I have spent a whole year trying to get my system back to the slim performance it had 1 year ago! I wish there was a wiki entry noting all of these issues before I began. (yes yes I can start one) (I also wish there was some sort of patching profiler ... but thats mabey another issue.)
*sigh* I've been getting burned by this for too long and I'm sitting here replacing gui objects.
Dan Wilcox danomatika.com robotcowboy.com
I've recently been working with 80MHz machines that don't even have
FPUs, so I also care about oooold machines. (These little computers
are known as "iPods").
One thing that is definitely worth trying is to update to the latest
version of Tcl/Tk. They have done a lot of optimization in 8.5, I
think on X11 too.
Another thing to try is writing the GUI in a toolkit that is optimized
for speed. I don't know if you have a GPU, but if you wrote Pd GUI
objects using something like togl or tkzinc, both use OpenGL, that
could also help.
http://togl.sourceforge.net/ http://www.tkzinc.org/
.hc
On May 25, 2009, at 6:03 PM, danomatika wrote:
I've been running pd on my slow wearable (500Mhz) and, over the last
year, the performance has gotten worse. This trend coincides with
my greater understanding of pd and adoption of nice GOP guis.So basically, all of the work I have done to make an easy to use
environment for making songs/patches is practically worthless as the
GOP/gui stuff kills the cpu on the wearable. Nobody seems to care
as we all have exponentially faster computers each day, which is too
bad as one of pd's strengths in my opinion is it's ability to run on
basically anything.I'm just wondering if there are others with slow cpu (iPhone RJDJ)
machines and how their approach to patching deals with this issue.Basically, I have spent a whole year trying to get my system back to
the slim performance it had 1 year ago! I wish there was a wiki
entry noting all of these issues before I began. (yes yes I can
start one) (I also wish there was some sort of patching profiler ...
but thats mabey another issue.)*sigh* I've been getting burned by this for too long and I'm sitting
here replacing gui objects.
Dan Wilcox danomatika.com robotcowboy.com _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
Hans-Christoph Steiner wrote:
I've recently been working with 80MHz machines that don't even have FPUs, so I also care about oooold machines. (These little computers are known as "iPods").
One thing that is definitely worth trying is to update to the latest version of Tcl/Tk. They have done a lot of optimization in 8.5, I think on X11 too.
Another thing to try is writing the GUI in a toolkit that is optimized for speed. I don't know if you have a GPU, but if you wrote Pd GUI objects using something like togl or tkzinc, both use OpenGL, that could also help.
i am still pretty convinced that tcl/tk is not the buster, so replacing it by someting more performant will only give you little help. the problem comes from how Pd(-core) communicates with the Pd-gui; and that Pd(-core) needs a lot of calculation power to make Pd-gui draw something nicely. unless this calculations are done on the Pd-gui side, i see little chances that things will improve.
having said all that, i honestly do not understand how the matter of CPU-hungry gop objects impose any problems on slow machines. you are surely not saying, that you develop your patches for iPod/wearables/P-100 andwhatelse with graphical objects.(?!)
personally i cannot imagine developing cpu-intensive patches on my current machine, which is a by-now-rather-oldish amd64 x2 dual-core (well, Pd cannot use more than 1 core anyhow) 4200+, with GOP enabled.
gfmasdr IOhannes
On Tue, 2009-05-26 at 09:07 +0200, IOhannes m zmoelnig wrote:
i am still pretty convinced that tcl/tk is not the buster, so replacing it by someting more performant will only give you little help. the problem comes from how Pd(-core) communicates with the Pd-gui; and that Pd(-core) needs a lot of calculation power to make Pd-gui draw something nicely. unless this calculations are done on the Pd-gui side, i see little chances that things will improve.
Yeah, that's what I think, knowing what little I do about the pd and pd-gui interaction.
having said all that, i honestly do not understand how the matter of CPU-hungry gop objects impose any problems on slow machines. you are surely not saying, that you develop your patches for iPod/wearables/P-100 andwhatelse with graphical objects.(?!)
Ahh, here's the point. You assume that people like me would know ahead of time not use those "stupid, hacky" gui objects with slow machines. As I said before, I assumed that -nogui meant "no gui" and that optimizations were in place to basically ignore the gui elements when run in -nogui mode. This assumption lead me to create an easy to use gui environment which facilitates my style of patching but is now biting me in the ass. I guess I should have RTFM, oh wait, where does it talk about this issue?
So your suggestion is to scrap all of this and use minimal objects again? What is this? 1999?
Forgive me for assuming pd is as awesome as I had hoped it would be.
personally i cannot imagine developing cpu-intensive patches on my current machine, which is a by-now-rather-oldish amd64 x2 dual-core (well, Pd cannot use more than 1 core anyhow) 4200+, with GOP enabled.
This is too bad ... so why are they even in pd? I see most people creating great GOP abstraction etc on what is essentially a hack more or less? I would probably be using Max by now if I didn't have the requirement of running my system on an essentially embedded device, which Max will never be able to do. Don't get me wrong, I really like using pd, but I'm not married to it.
Heaven forbid pd becomes more usable to public at large.
I suppose I can't bitch because with open source, I "get what I pay for". I am, however, willing to work on this. Here's an email I tried to send to pd-dev, but I don't really feel like adding a new mailing list so I'll quote it here:
There are issues I have with pd (GOP/GUI slowness, -nogui slowness, etc) and I'm wondering if there are any residencies/places to apply to work on pd. I know C/C++ but I have not, at this time, really looked into the source very much as I know I just do not have the time to do anything meaningful on the side.
I have no intention of rewriting pd etc, I'm mainly interested in gui optimizations so that I can run GOP patches on my wearable without the damn vus and number boxes killing the cpu.
Yeah yeah, I'm probably full of shit for saying the same old things about the same old problems, but I would very much like to try solving some of them. One of the reasons I use pd, is that I can see myself using my gear for a long time into the future.
Dan Wilcox danomatika.com robotcowboy.com
On Tue, May 26, 2009 at 7:37 AM, danomatika danomatika@gmail.com wrote:
So your suggestion is to scrap all of this and use minimal objects again? What is this? 1999?
I think that, pd's inefficiencies aside, if you are developing for embedded devices with limited computing resources, you should always pretend you're in 1999.
This is too bad ... so why are they even in pd? I see most people creating great GOP abstraction etc on what is essentially a hack more or less?
There was an effort once, in its latest incarnation was called Desire Data, to separate the gui from the core, the client from the server and optimize things but I think it is now in a coma.
I would probably be using Max by now if I didn't have the requirement of running my system on an essentially embedded device, which Max will never be able to do. Don't get me wrong, I really like using pd, but I'm not married to it.
Do you think Max would run more reliably and efficiently than pd? I never tried Max on an embedded device (it would be impossible, as you point out, unless that device was already running windows or MaxOSX) but in my experience Max is not, be default, more efficient or reliable than Pd. It really is context (and code) dependent.
Yes, pd could benefit from a face-lift and optimization and whatnot to make it more user-friendly and more pleasant to work with (and more efficient!). So far, most proposed changes were somehow ignored or set aside and various branches of pd or pd-like projects never lifted off the ground.
my 0.02
On Tue, 2009-05-26 at 08:33 -0400, Michal Seta wrote:
On Tue, May 26, 2009 at 7:37 AM, danomatika danomatika@gmail.com wrote:
So your suggestion is to scrap all of this and use minimal objects again? What is this? 1999?
I think that, pd's inefficiencies aside, if you are developing for embedded devices with limited computing resources, you should always pretend you're in 1999.
Yes, totally right ... I just wish it weren't so! I do manage realtime with 10ms latency on a 500Mhz machine though which is nothing to sneeze at, but dosen't leave much room aside.
This is too bad ... so why are they even in pd? I see most people creating great GOP abstraction etc on what is essentially a hack more or less?
There was an effort once, in its latest incarnation was called Desire Data, to separate the gui from the core, the client from the server and optimize things but I think it is now in a coma.
Yeah I know ... but it seemed to be trying to reach a bit too far too quickly.
I would probably be using Max by now if I didn't have the requirement of running my system on an essentially embedded device, which Max will never be able to do. Don't get me wrong, I really like using pd, but I'm not married to it.
Do you think Max would run more reliably and efficiently than pd? I never tried Max on an embedded device (it would be impossible, as you point out, unless that device was already running windows or MaxOSX) but in my experience Max is not, be default, more efficient or reliable than Pd. It really is context (and code) dependent.
No, Max would be terrible for my requirements. But it's nice to use from what I've seen ...
My point is, I wish pd didn't force me to work it's way but allow me to work my way. That's the beauty of patching as opposed to vsts, etc. You have to build form the ground up.
Yes, pd could benefit from a face-lift and optimization and whatnot to make it more user-friendly and more pleasant to work with (and more efficient!). So far, most proposed changes were somehow ignored or set aside and various branches of pd or pd-like projects never lifted off the ground.
What is the state of all these changes? As I said before, I'm willing to help but not if said changes and progress won't go anywhere, then count me out. I'd rather just learn some dsp and do it myself because at least I would be able to make changes depending on my needs. Of course, then I'd waste even more time programming and not playing ... *sigh*
pd is great, but it's like getting kicked in the balls and face sometimes.
I LIKE LINUX AND .' . GETTING KICKED IN --- |a_a | THE BALLS AND FACE \<_)__/ /( )\ |\> < /
_|=='|_/
Dan Wilcox danomatika.com robotcowboy.com
Hallo, danomatika hat gesagt: // danomatika wrote:
My point is, I wish pd didn't force me to work it's way but allow me to work my way. That's the beauty of patching as opposed to vsts, etc. You have to build form the ground up.
Well, Pd is a programming language, and as with all language, you can say things you'd have wished you didn't say or with programming: It easy to overload any machine (bang until) with a programming language.
For working with GUIs there is a simple rule that applies to other areas as well:
Remove cruft!
This means, everything that updates a GUI object more that you screen refresh rate is totally useless. Any GUI that you never see because it's hidden in some abstraction is useless. Remove the useless GUIs, speedlimit the the needed ones and your patch will run fast. It may even help to get used to a clean design where you have your GUIs in separate patches from DSP or message stuff.
It doesn't matter if it's in a GOP or not. GOPs aren't slow per se, it's just that GOPs make it easier to build useless GUIs. Remove stuff that you won't touch when performing.
Yes, Pd should handle this this automatically and more gracefully, but it doesn't and it never did, so all that changed is probably your patching style.
Ciao
Frank
On Tue, May 26, 2009 at 03:34:51PM +0200, Frank Barknecht wrote:
Hallo, danomatika hat gesagt: // danomatika wrote:
My point is, I wish pd didn't force me to work it's way but allow me to work my way. That's the beauty of patching as opposed to vsts, etc. You have to build form the ground up.
Well, Pd is a programming language, and as with all language, you can say things you'd have wished you didn't say or with programming: It easy to overload any machine (bang until) with a programming language.
I have to say that with most programming languages an infinite loop does not mean an X crash. Probably I should contribute code, not words (sorry).
Best,
Chris.
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Tue, May 26, 2009 at 03:34:51PM +0200, Frank Barknecht wrote:
Hallo, danomatika hat gesagt: // danomatika wrote:
My point is, I wish pd didn't force me to work it's way but allow me to work my way. That's the beauty of patching as opposed to vsts, etc. You have to build form the ground up.
Well, Pd is a programming language, and as with all language, you can say things you'd have wished you didn't say or with programming: It easy to overload any machine (bang until) with a programming language.
I have to say that with most programming languages an infinite loop does not mean an X crash. Probably I should contribute code, not words (sorry).
I never had X crash with bang-until, so that's new to me. However a loop in an audio language can be worse than in a "normal" programm, as software like Pd often is run with higher priorities to get better latency performance. Of course then an endless loop is a bit trickier to get out of. :(
Ciao
Frank
On Tue, May 26, 2009 at 04:30:24PM +0200, Frank Barknecht wrote:
Hallo, Chris McCormick hat gesagt: // Chris McCormick wrote:
On Tue, May 26, 2009 at 03:34:51PM +0200, Frank Barknecht wrote:
Hallo, danomatika hat gesagt: // danomatika wrote:
My point is, I wish pd didn't force me to work it's way but allow me to work my way. That's the beauty of patching as opposed to vsts, etc. You have to build form the ground up.
Well, Pd is a programming language, and as with all language, you can say things you'd have wished you didn't say or with programming: It easy to overload any machine (bang until) with a programming language.
I have to say that with most programming languages an infinite loop does not mean an X crash. Probably I should contribute code, not words (sorry).
I never had X crash with bang-until, so that's new to me. However a loop in an audio language can be worse than in a "normal" programm, as software like Pd often is run with higher priorities to get better latency performance. Of course then an endless loop is a bit trickier to get out of. :(
Wow, I am so wrong. Please forgive me for this FUD!
Chris.
Am 26.05.2009 um 16:23 schrieb Chris McCormick:
On Tue, May 26, 2009 at 03:34:51PM +0200, Frank Barknecht wrote:
Hallo, danomatika hat gesagt: // danomatika wrote:
My point is, I wish pd didn't force me to work it's way but allow
me to work my way. That's the beauty of patching as opposed to vsts, etc. You have to build form the ground up.Well, Pd is a programming language, and as with all language, you
can say things you'd have wished you didn't say or with programming: It
easy to overload any machine (bang until) with a programming language.I have to say that with most programming languages an infinite loop
does not mean an X crash. Probably I should contribute code, not words (sorry).
hm.. with what kind of setup have you experienced that? on ubuntu
hardy with pd-vanilla (newest) and pd-extended, with -rt or -nrt, i
never managed to do that.
only when running gem in fullscreen mode and pd goes into a loop, i
had a similar looking situation, but still then i could switch to a
terminal and kill pd from there.
roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On May 26, 2009, at 10:23 AM, Chris McCormick wrote:
On Tue, May 26, 2009 at 03:34:51PM +0200, Frank Barknecht wrote:
Hallo, danomatika hat gesagt: // danomatika wrote:
My point is, I wish pd didn't force me to work it's way but allow
me to work my way. That's the beauty of patching as opposed to vsts, etc. You have to build form the ground up.Well, Pd is a programming language, and as with all language, you
can say things you'd have wished you didn't say or with programming: It
easy to overload any machine (bang until) with a programming language.I have to say that with most programming languages an infinite loop
does not mean an X crash. Probably I should contribute code, not words (sorry).
Just because Pd triggers an X crash does it mean that Pd is the cause
of it. A similar example is when people complain that Pd blue screens
their windows box, as I have seen before. That's generally because
some of the PC audio hardware and Windows drivers are so atrocious
that actually using them beyond playing back youtube videos causes
BSODs.
In other words, the cause of your X crash likely lies elsewhere.
.hc
Best,
Chris.
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Am 26.05.2009 um 15:04 schrieb danomatika:
My point is, I wish pd didn't force me to work it's way but allow me
to work my way. That's the beauty of patching as opposed to vsts,
etc. You have to build form the ground up.
i don't fully understand, why you feel forced to program in a certain
way. actually, pd gives you the freedom to go the route you prefer:
fancy-clicky-boonty or straight and efficient (or anything in between).
i guess, a common approach is to first define the goals and then chose
the programming style/software layout, that is most compliant with the
goals. in your case, the goal is pretty clear: performance. of course,
there are some contraints, when going that route, but _you_ decided,
that your goal is performance.
some things, that come to my mind, when thinking about optimizing
performance (additionally to what has been already said by frank b.):
- turn off the dsp for any unused subpatches/abstractions with
[switch~].
- don't do too many things in zero logical time. the lower the
latency, the more critical is this issue. try to avoid such situations
by serializing the tasks.
- avoid dynamic patching during performance. if you still need it,
first turn off dsp, create the necessary objects, turn dsp on again
(triggered by [t b b b]). don't do dynamic patching, while dsp is on
(this certainly applies to linux, but i guess not to pd on os x, since
only turning the dsp on uses too much time).
- be careful with any object, that might block pd. especially, this
applies to object classes, that send data to the extra-pd-world, such
as netsend, comport, (midiout?), etc.
yo, i guess, most of it doesn't really help optimizing performance in
terms of using less cpu cycles, but is about avoiding audio drop-outs.
however, this is not less an issue on a 500MHz machine.
cheers roman
___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
On May 26, 2009, at 3:07 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
I've recently been working with 80MHz machines that don't even have
FPUs, so I also care about oooold machines. (These little
computers are known as "iPods"). One thing that is definitely worth trying is to update to the
latest version of Tcl/Tk. They have done a lot of optimization in
8.5, I think on X11 too. Another thing to try is writing the GUI in a toolkit that is
optimized for speed. I don't know if you have a GPU, but if you
wrote Pd GUI objects using something like togl or tkzinc, both use
OpenGL, that could also help. http://togl.sourceforge.net/ http://www.tkzinc.org/i am still pretty convinced that tcl/tk is not the buster, so
replacing it by someting more performant will only give you little
help. the problem comes from how Pd(-core) communicates with the Pd-gui;
and that Pd(-core) needs a lot of calculation power to make Pd-gui
draw something nicely. unless this calculations are done on the Pd- gui side, i see little chances that things will improve.having said all that, i honestly do not understand how the matter of
CPU-hungry gop objects impose any problems on slow machines. you are
surely not saying, that you develop your patches for iPod/wearables/ P-100 andwhatelse with graphical objects.(?!)personally i cannot imagine developing cpu-intensive patches on my
current machine, which is a by-now-rather-oldish amd64 x2 dual-core
(well, Pd cannot use more than 1 core anyhow) 4200+, with GOP enabled.
Yeah, I agree that the communications are a big part of it. Part of
writing a custom GUI would be to write a simple communications to suit
the needs at hand.
But I think that the slowness in Pd's GUI is not even that much due to
communications, but rather how the code is structured. For example,
if you move on element in an array, instead of issuing a single Tk
'move' command, Pd deletes the whole array, then recreates it.
And Dan, I also share your frustration with the common attitude on
this list of "it is what it is". That's why I am working on re-
writing the Pd GUI from scratch in pure Tcl with the aim of making it
use Tcl/Tk is a clean and sensible manner (aka Pd-devel 0.41.4). I
think you should join the project. Instead of venting via email, vent
via code.
As for replacing Pd with SuperCollider or C/rtaudio, are you sure that
those are any more efficient? Pd does have its problems, but audio
synthesis is pretty solid in Pd. For example, reactable still uses Pd
as its synth engine.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
Hans-Christoph Steiner wrote:
Yeah, I agree that the communications are a big part of it. Part of writing a custom GUI would be to write a simple communications to suit the needs at hand.
But I think that the slowness in Pd's GUI is not even that much due to communications, but rather how the code is structured. For example, if you move on element in an array, instead of issuing a single Tk 'move' command, Pd deletes the whole array, then recreates it.
this is (among other things) what i mean by "busted communication".
And Dan, I also share your frustration with the common attitude on this list of "it is what it is". That's why I am working on re-writing the Pd GUI from scratch in pure Tcl with the aim of making it use Tcl/Tk is a clean and sensible manner (aka Pd-devel 0.41.4).
oh, i thought you wanted miller to include the code of Pd-devel...seems like you got off the track :-(
which is bad, because Pd could also benefit from small improvements on the gui side quite a lot. which is good, because it really needs to be done. my email was just a rant on how bad things really are at the moment, and that i would like to have them changed. but which is really bad, as i think this is what desire-data originally started as (and btw, i see much activity on desiredata in the last days/weeks) and which basically forked away from Pd (certainly for understandable reasons; but i always had the impression that the reviving of Pd-devel was not intended as a fork)
fgamsdr IOhannes
On May 26, 2009, at 1:52 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Yeah, I agree that the communications are a big part of it. Part
of writing a custom GUI would be to write a simple communications
to suit the needs at hand. But I think that the slowness in Pd's GUI is not even that much due
to communications, but rather how the code is structured. For
example, if you move on element in an array, instead of issuing a
single Tk 'move' command, Pd deletes the whole array, then
recreates it.this is (among other things) what i mean by "busted communication".
And Dan, I also share your frustration with the common attitude on
this list of "it is what it is". That's why I am working on re- writing the Pd GUI from scratch in pure Tcl with the aim of making
it use Tcl/Tk is a clean and sensible manner (aka Pd-devel 0.41.4).oh, i thought you wanted miller to include the code of Pd- devel...seems like you got off the track :-(
Um, how is this mutually exclusive? My motivation in working on pd- devel is unchanged.
which is bad, because Pd could also benefit from small improvements
on the gui side quite a lot. which is good, because it really needs to be done. my email was just
a rant on how bad things really are at the moment, and that i would
like to have them changed. but which is really bad, as i think this is what desire-data
originally started as (and btw, i see much activity on desiredata in
the last days/weeks) and which basically forked away from Pd
(certainly for understandable reasons; but i always had the
impression that the reviving of Pd-devel was not intended as a fork)
From what I gather, Miller is more or less game for including that
work. My plan is to spend June and July working on Pd-devel to get it
to a fully usable state so that we can discuss it at PdCon. I hope
that others will join me in that effort.
In particular, I want to structure the code around the idea of a
communications API that uses Pd messages for both directions. For
now, it will use the existing pd<-->pd-gui API, then the next step
would be working on the C side of things once Miller has included it.
.hc
fgamsdr IOhannes
I have the audacity to believe that peoples everywhere can have three
meals a day for their bodies, education and culture for their minds,
and dignity, equality and freedom for their spirits. - Martin
Luther King, Jr.
Hans-Christoph Steiner wrote:
On May 26, 2009, at 1:52 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Yeah, I agree that the communications are a big part of it. Part of writing a custom GUI would be to write a simple communications to suit the needs at hand. But I think that the slowness in Pd's GUI is not even that much due to communications, but rather how the code is structured. For example, if you move on element in an array, instead of issuing a single Tk 'move' command, Pd deletes the whole array, then recreates it.
this is (among other things) what i mean by "busted communication".
And Dan, I also share your frustration with the common attitude on this list of "it is what it is". That's why I am working on re-writing the Pd GUI from scratch in pure Tcl with the aim of making it use Tcl/Tk is a clean and sensible manner (aka Pd-devel 0.41.4).
oh, i thought you wanted miller to include the code of Pd-devel...seems like you got off the track :-(
Um, how is this mutually exclusive? My motivation in working on pd-devel is unchanged.
it is mutually exclusive by what miller has said on this topic. i wish it wasn't
From what I gather, Miller is more or less game for including that work.
[...]
In particular, I want to structure the code around the idea of a communications API that uses Pd messages for both directions. For now, it will use the existing pd<-->pd-gui API, then the next step would be working on the C side of things once Miller has included it.
as far as i understand it, miller has stated several times explicitely that he is fine with re-structuring the tcl/tk code. however (and this is the crucial part), he is not going to accept any substantial changes to the C-part of it. hopefully this will change.
if i had more time, i would have started this myself several times...
fmasdr IOhannes
On May 27, 2009, at 2:43 AM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
On May 26, 2009, at 1:52 PM, IOhannes m zmoelnig wrote:
Hans-Christoph Steiner wrote:
Yeah, I agree that the communications are a big part of it. Part
of writing a custom GUI would be to write a simple communications
to suit the needs at hand. But I think that the slowness in Pd's GUI is not even that much
due to communications, but rather how the code is structured.
For example, if you move on element in an array, instead of
issuing a single Tk 'move' command, Pd deletes the whole array,
then recreates it.this is (among other things) what i mean by "busted communication".
And Dan, I also share your frustration with the common attitude
on this list of "it is what it is". That's why I am working on
re-writing the Pd GUI from scratch in pure Tcl with the aim of
making it use Tcl/Tk is a clean and sensible manner (aka Pd-devel
0.41.4).oh, i thought you wanted miller to include the code of Pd- devel...seems like you got off the track :-(
Um, how is this mutually exclusive? My motivation in working on pd- devel is unchanged.
it is mutually exclusive by what miller has said on this topic. i wish it wasn't
From what I gather, Miller is more or less game for including that
work.[...]
In particular, I want to structure the code around the idea of a
communications API that uses Pd messages for both directions. For
now, it will use the existing pd<-->pd-gui API, then the next step
would be working on the C side of things once Miller has included it.as far as i understand it, miller has stated several times
explicitely that he is fine with re-structuring the tcl/tk code. however (and this is the crucial part), he is not going to accept
any substantial changes to the C-part of it. hopefully this will change.if i had more time, i would have started this myself several times...
I think you are crying wolf here (or rather crying "fork"), and I
don't see any reason why. The idea of this pd-devel effort has not
changed, from what Miller's told me, the work is acceptable to him.
And the code is being structured to use Tcl/Tk better. I am hoping
for more submissions from people who know Tcl/Tk better to go in that
direction. I am also hoping to lay the groundwork for the C-side
changes which will come later.
.hc
Information wants to be free. -Stewart Brand
On Tue, 2009-05-26 at 13:05 -0400, Hans-Christoph Steiner wrote:
And Dan, I also share your frustration with the common attitude on
this list of "it is what it is". That's why I am working on re- writing the Pd GUI from scratch in pure Tcl with the aim of making it
use Tcl/Tk is a clean and sensible manner (aka Pd-devel 0.41.4). I
think you should join the project. Instead of venting via email, vent
via code.
Ok, where do I sign up? As I said before, if anyone knows of any places
I can apply to in order to focus on it full time, I'm interested. I have known of your efforts for a while, but I haven't wanted to commit a small amount of time, I'd rather dive in head first. I don;t want to waste anyone's time telling them I can do this and that knowing full well I won't really end up doing anything.
As for replacing Pd with SuperCollider or C/rtaudio, are you sure that
those are any more efficient? Pd does have its problems, but audio
synthesis is pretty solid in Pd. For example, reactable still uses Pd
as its synth engine.
I totally agree, that's why I keep sticking with pd. I can't imagine being able to make anything nearly as efficient as the pd dsp engine. That being said, I wish it wasn't being pummled by the gui. I very much like this idea of a libpd with the engine totally separate.
Dan Wilcox danomatika.com robotcowboy.com
On May 26, 2009, at 2:13 PM, danomatika wrote:
On Tue, 2009-05-26 at 13:05 -0400, Hans-Christoph Steiner wrote:
And Dan, I also share your frustration with the common attitude on this list of "it is what it is". That's why I am working on re- writing the Pd GUI from scratch in pure Tcl with the aim of making it use Tcl/Tk is a clean and sensible manner (aka Pd-devel 0.41.4). I think you should join the project. Instead of venting via email,
vent via code.Ok, where do I sign up? As I said before, if anyone knows of any
places I can apply to in order to focus on it full time, I'm interested. I
have known of your efforts for a while, but I haven't wanted to commit a small amount of time,
I'd rather dive in head first. I don;t want to waste anyone's time telling them I can do
this and that knowing full well I won't really end up doing anything.
svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-devel/0.41... cd 0.41.4 ./authgen.sh ./configure make && ./pd
Get it running, check out the code, pick a part and write code.
Introduce yourself to pd-dev to get SVN access, if you don't have it
already.
As for replacing Pd with SuperCollider or C/rtaudio, are you sure
that those are any more efficient? Pd does have its problems, but audio synthesis is pretty solid in Pd. For example, reactable still uses
Pd as its synth engine.I totally agree, that's why I keep sticking with pd. I can't
imagine being able to make anything nearly as efficient as the pd dsp engine. That being said, I wish
it wasn't being pummled by the gui. I very much like this idea of a libpd with the engine
totally separate.
Check out the next external scheduler support and pdvst and make this
happen.
.hc
All mankind is of one author, and is one volume; when one man dies,
one chapter is not torn out of the book, but translated into a better
language; and every chapter must be so translated.... -John Donne
On Mon, May 25, 2009 at 6:03 PM, danomatika danomatika@gmail.com wrote:
I've been running pd on my slow wearable (500Mhz) and, over the last year, the performance has gotten worse. This trend coincides with my greater understanding of pd and adoption of nice GOP guis.
The first live video processing system I built in 2001 with Casey Rice used 400Mhz machines, and we had no problems with doing what we wanted to do. It required a lot of research into the video medium, OS APIs, and this frustrating black box called Nato. Once you understand the limits of what you are dealing with, forget about them and get down to work.
On Tue, 2009-05-26 at 08:34 -0400, chris clepper wrote:
On Mon, May 25, 2009 at 6:03 PM, danomatika danomatika@gmail.com wrote:
I've been running pd on my slow wearable (500Mhz) and, over the last year, the performance has gotten worse. This trend coincides with my greater understanding of pd and adoption of nice GOP guis.The first live video processing system I built in 2001 with Casey Rice used 400Mhz machines, and we had no problems with doing what we wanted to do. It required a lot of research into the video medium, OS APIs, and this frustrating black box called Nato. Once you understand the limits of what you are dealing with, forget about them and get down to work.
Yeah, I'm definitely learning this. I do enjoy the creative limitations actually, it's just that things ran "so much better" a year ago with Ubuntu Hardy + Pd-extended 0.39 ... Perhaps I'm at the point where I just need to reimplement what I have now in C/C++ using rt audio, etc but that would take time of course. I originally started using pd just to prototype anyway ...
Dan Wilcox danomatika.com robotcowboy.com
On Tue, May 26, 2009 at 8:53 AM, danomatika danomatika@gmail.com wrote:
Yeah, I'm definitely learning this. I do enjoy the creative limitations actually, it's just that things ran "so much better" a year ago with Ubuntu Hardy + Pd-extended 0.39 ... Perhaps I'm at the point where I just need to reimplement what I have now in C/C++ using rt audio, etc but that would take time of course. I originally started using pd just to prototype anyway ...
I would suggest moving to SuperCollider to save a step. It's pretty quick to prototype with, and as fast as writing the C yourself.
-
chris clepper -
Chris McCormick -
danomatika -
Frank Barknecht -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
Michal Seta -
Roman Haefeli