hi, im trying to make a granular synthesis patch.... but i dont know why the patch consumes almost all of my cpu...and im just using 10 grains!!
do u experience the same? do anybody have any hint? any idea , suggestion or whatever would be appreciated.
heres is the patch:
http://www.racapapu.net/acne.pd
bye
punchik
pun chik punchik@fastmail.fm
Hallo, pun chik hat gesagt: // pun chik wrote:
hi, im trying to make a granular synthesis patch.... but i dont know why the patch consumes almost all of my cpu...and im just using 10 grains!!
do u experience the same? do anybody have any hint?
You are using many many GUI objects in places where they are not needed at all, except maybe for debugging. Pd however has to update and check all these objects which costs time. Newer Pd-versions aren't as bad anymore as older ones with this, but still I'm sure you can get a much better performance out of your patch, if you go through it and remove all unnecessary numbers and GUI bangs.
If you want to see a number somewhere, say after a float, and you might not need that number later on, then don't make a connection *through* the number, but "fork" a connection to the number, and remove the number later. So this is bad:
[r something] |__ [0_\ <== number | [s somewhere]
but this is okay:
[r something] | __ | [0_\ <== number | [s somewhere]
because in the second version, you can delete the number or disconnect it without breaking your patch and it will save a bit CPU power.
At some places in your patch you also misuse number objects as receivers - that is, you have a hidden receive inside a number, but the number itself is hidden somewhere deeply, so it's obviously not necessary, to use a number object at all here. Replace this with a real receiver like [r something] and you will save CPU again.
Then you also tend to use too many graphical bangs, where a normal [t b] object would be more than enough and even more appropriate. Banging GUI bangs very often will cost precious CPU time. Just say no to the GUI bang!
So the general rule would be: Use the GUI elements only there, where you need them, either for visual feedback or for value input. Remove or disconnect them everywhere else. I guess, you will get an immense performance boost by this if you had many GUI objects in your patch.
Other than that I couldn't spot anything obvious at my quick look at your patch which could be responsible for the rather high load it generates, so I'm really sure it is the GUI object "abuse". ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
i just deleted all the unnecessary gui elements in all my complex patches and now they run really fast!! thanks frank!, now i love pd again!!!!!!!
punchik
On Sat, 3 Sep 2005 00:43:00 +0200, "Frank Barknecht" fbar@footils.org said:
Hallo, pun chik hat gesagt: // pun chik wrote:
hi, im trying to make a granular synthesis patch.... but i dont know why the patch consumes almost all of my cpu...and im just using 10 grains!!
do u experience the same? do anybody have any hint?
You are using many many GUI objects in places where they are not needed at all, except maybe for debugging. Pd however has to update and check all these objects which costs time. Newer Pd-versions aren't as bad anymore as older ones with this, but still I'm sure you can get a much better performance out of your patch, if you go through it and remove all unnecessary numbers and GUI bangs.
If you want to see a number somewhere, say after a float, and you might not need that number later on, then don't make a connection *through* the number, but "fork" a connection to the number, and remove the number later. So this is bad:
[r something] |__ [0_\ <== number | [s somewhere]
but this is okay:
[r something] | __ | [0_\ <== number | [s somewhere]
because in the second version, you can delete the number or disconnect it without breaking your patch and it will save a bit CPU power.
At some places in your patch you also misuse number objects as receivers - that is, you have a hidden receive inside a number, but the number itself is hidden somewhere deeply, so it's obviously not necessary, to use a number object at all here. Replace this with a real receiver like [r something] and you will save CPU again.
Then you also tend to use too many graphical bangs, where a normal [t b] object would be more than enough and even more appropriate. Banging GUI bangs very often will cost precious CPU time. Just say no to the GUI bang!
So the general rule would be: Use the GUI elements only there, where you need them, either for visual feedback or for value input. Remove or disconnect them everywhere else. I guess, you will get an immense performance boost by this if you had many GUI objects in your patch.
Other than that I couldn't spot anything obvious at my quick look at your patch which could be responsible for the rather high load it generates, so I'm really sure it is the GUI object "abuse". ;)
Ciao
Frank Barknecht _ ______footils.org__
_ __latest track: "plak" @ http://footils.org/cms/show/44
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Could you send out the edited patch?
~Kyle
On 9/2/05, pun chik punchik@fastmail.fm wrote:
i just deleted all the unnecessary gui elements in all my complex patches and now they run really fast!! thanks frank!, now i love pd again!!!!!!!
punchik
-
Frank Barknecht -
Kyle Klipowicz -
pun chik