Hi,
I've made this abstraction, which is a GOP. It's a normal volume
controller, audio on left sides (up+down), and level on right sides.
But when I turn audio on, my CPU jumps to around 40% (Thinkpad 1.5Mhz,
XP). That has nothing to do with how much signal is being processed by pd,
I guess only with the updating of (semi-)Audio-Rate information by tcl/tk,
which seems to be quite expensive.
Is this only a windows issue, or is it a general problem from tcl/tk? Is
it possible in any way to make an abstraction which can update
(semi-)audio-rate information?
Thanks,
Joao
hi joão
you could change [env~] to [env~ 8192], so that it only outputs a number every 8192 samples, so the vu-meter does not get updated that often. actually there are three different rates in pd, sampling-rate (audio), control rate (normally sr/64) and then the gui update rate. with a normal [env~], the vu-meter is updated every 1.5ms. althoug the refresh rate of the screen is much lower, it seems, that calculation of updating is done on every message (at least on windows).
roman
From: "João Miguel Pais" jmmmpais@googlemail.com wrote:
Hi,
I've made this abstraction, which is a GOP. It's a normal volume controller, audio on left sides (up+down), and level on right sides.
But when I turn audio on, my CPU jumps to around 40% (Thinkpad 1.5Mhz, XP). That has nothing to do with how much signal is being processed by pd, I guess only with the updating of (semi-)Audio-Rate information by tcl/tk, which seems to be quite expensive. Is this only a windows issue, or is it a general problem from tcl/tk? Is it possible in any way to make an abstraction which can update (semi-)audio-rate information?
Thanks,
Joao
___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
you could change [env~] to [env~ 8192], so that it only outputs a number
every 8192 samples, so the vu-meter does not get updated that often. actually there are three different rates in pd, sampling-rate (audio),
control rate (normally sr/64) and then the gui update rate. with a
normal [env~], the vu-meter is updated every 1.5ms. althoug the refresh
rate of the screen is much lower, it seems, that calculation of updating
is done on every message (at least on windows).
so you mean, that for GOPs or GUIs in general it is better to use tcl/tk's
refresh rate, which is the K-rate? with env~ 8820 it spends the half cpu
as before, but anyway still too much for such a simple thing, I guess.
On Sun Feb 12, 2006 at 10:47:29PM +0100, Jo?o Miguel Pais wrote:
you could change [env~] to [env~ 8192], so that it only outputs a number
every 8192 samples, so the vu-meter does not get updated that often. actually there are three different rates in pd, sampling-rate (audio),
control rate (normally sr/64) and then the gui update rate. with a
normal [env~], the vu-meter is updated every 1.5ms. althoug the refresh
rate of the screen is much lower, it seems, that calculation of updating
is done on every message (at least on windows).so you mean, that for GOPs or GUIs in general it is better to use tcl/tk's
refresh rate, which is the K-rate? with env~ 8820 it spends the half cpu
as before, but anyway still too much for such a simple thing, I guess.
you could launch pd with the '-d 3' argument to see what exactly its telling the GUI to do. if its deleting and recreating the widget from scratch for each update, thats a problem. if its just sending over a list of floats, thats significantly better.. i know using the latter technique it was no problem to do 25 fps full-color spectrograms/response-graphs with only about 2% CPU load on WinXP/a64-2.0ghz. so its definitely possible.. there are diminishing returns in terms of bandwidth and cpu usage vs percieved smoothness after about 20 or 25 fps..
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
cdr -
João Miguel Pais -
Roman Haefeli