dear list,
I have a patch which is a simple sample player (with xgroove~), with graphical display of the array and the reading point. I intend to have simultaneous copies (4 to 8) of the patch running together, so I made it an abstraction with gop.
I suspect that there is a problem with the tcl-tk progam: when I try to move the patch it waits a few seconds (!) if I drag-and-drop, and then it goes very slowly. but worse, when I put two abstractions in the same patch, the cpu shoots to minimum 80% (dsp state doesn't matter). in case I open several times the same patch with one abstraction, the cpu goes only to 15% (it's still too much, but not to compare with before)
were there any problems with tcl-tk reported lately? I'm running xp, 0.38.3
thank you,
João Miguel Pais
Lugostr. 14 79100 Freiburg i. Br. Deutschland +49 (0)761 7074997 jmmmp@arcor.de
jmmmp wrote:
I have a patch which is a simple sample player (with xgroove~), with graphical display of the array and the reading point.
I'm afraid that's your problem right there. Visible arrays in PD are one of the most costly things you can do, especially if they are updated in realtime. [Try having a whole bank of VU meters, and you'll get the same overload...] Try hiding the arrays and you will probably see a dramtic decrease in CPU usage. Sorry...
d.
maybe I didn't explained well:
the array is visible, but it gets loaded once and remains so (dimensions 200x90, not big). the reading point is made by a hslider which is behind the array, so that should be quite cheap in fact. it also happens that sometimes when I have more than one array the sound gets distorted and remains so when I quit the patch (and load the standard audio-test patch, for example). the behaviour is in general a bit erratic, I can't also determine exactly when it will go wrong or not. but I'm sure that it didn't happened like that before, so I don't know if I have the wrong version of tcl-tk or something.
for example I made some time ago a graphical oscilator which also works as a gop, which was a (bigger) array being continuously actualized (one can define how often), and it worked with no problems. something that I also don't understand is why the gop takes the double of the necessary and defined horizontal space.
I send attached a copy of the pestering patch, I think it is small enough. load the spieler-4, sa-sp is the abstraction.
Joao
----- Original Message ----- From: "derek holzer" derek@x-i.net To: "jmmmp" jmmmpl@netcabo.pt Cc: "PD list" pd-list@iem.kug.ac.at Sent: Friday, May 20, 2005 12:18 PM Subject: Re: [PD] gop / tcl-tk cpu overload
jmmmp wrote:
I have a patch which is a simple sample player (with xgroove~), with graphical display of the array and the reading point.
I'm afraid that's your problem right there. Visible arrays in PD are one of the most costly things you can do, especially if they are updated in realtime. [Try having a whole bank of VU meters, and you'll get the same overload...] Try hiding the arrays and you will probably see a dramtic decrease in CPU usage. Sorry...
d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 84: "How would you have done it?"
hi jm,
jmmmp wrote: ...
I suspect that there is a problem with the tcl-tk progam: when I try to move the patch it waits a few seconds (!) if I drag-and-drop, and then it goes
just the opposite... it is slow, because the movement is not handled directly by the tcl/tk layer. One problem is the C program doing an awful lot of redundant work. Another problem is the amount of data unnecessarily transferred between both ends (btw, early 0.38 versions are buggy in that part). Lastly, there is the problem of the connection itself, which is particularly inefficient in your system.
were there any problems with tcl-tk reported lately? I'm running xp, 0.38.3
the latter problem was discussed recently, but not a single xp user seemed to care...
Krzysztof
-
derek holzer -
jmmmp -
Krzysztof Czaja