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 > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
