I found at least one tcl-error bug and tried to fix it... can you try this version...
http://msp.ucsd.edu/tmp/pd-tmp.msw.zip http://msp.ucsd.edu/tmp/pd-tmp.windows-installer.exe
thanks Miller
On Mon, Sep 25, 2017 at 05:35:55PM +0200, Roman Haefeli wrote:
On Sam, 2017-09-23 at 08:45 -0400, Ivica Bukvic wrote:
This is likely dur to a buggy implementation of a particular widget redrawing which may be a third-party widget.
In my case I use only vanilla widgets, I but can't tell if it is caused by a single kind or rather by the number of them all combined.Â
It may be also due to out of sequence execution of commands in case the widget does not enqueue all it's GUI commands like it should. One way pd-l2ork 1.0 dresses this which is an ugly workaround but at least it prevents you from losing GUI in the middle of a performance is to process all TCL commands using the try/catch command (can't remember the right syntax). This way if a TCL command fails, the GUI will remain responsive. It is possible this introduces an additional overhead in terms of CPU usage even though I have not observed any.
I very much would prefer this over what we have now. Not updating a bunch of events wouldn't be as bad as losing the whole stream like now.
Maybe I make totally wrong assumptions, but I can't see how the fault can be on the widgets end since what suddenly fails is the path pd -> GUI, not the other way.Â
BTW, neither of both processes, pd and wish, necessarily have a CPU load at 100% when this happens. So, what is the bottleneck here? I don't think it is the network connection to localhost.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list