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?"