<div dir="auto">This is likely dur to a buggy implementation of a particular widget redrawing which may be a third-party widget. 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.<div dir="auto"><br></div><div dir="auto">Best,</div><div dir="auto"><br></div><div dir="auto">Ico<br><br><div data-smartmail="gmail_signature" dir="auto">-- <br>Ivica Ico Bukvic, D.M.A.<br>Associate Professor<br>Computer Music<br>ICAT Senior Fellow<br>Director -- DISIS, L2Ork<br>Virginia Tech<br>School of Performing Arts – 0141<br>Blacksburg, VA 24061<br>(540) 231-6139<br><a href="mailto:ico@vt.edu">ico@vt.edu</a><br><a href="http://www.performingarts.vt.edu">www.performingarts.vt.edu</a><br><a href="http://disis.icat.vt.edu">disis.icat.vt.edu</a><br><a href="http://l2ork.icat.vt.edu">l2ork.icat.vt.edu</a><br><a href="http://ico.bukvic.net">ico.bukvic.net</a></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sep 23, 2017 08:08, "Roman Haefeli" <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
BTW, A friend of mine and me, we have been experiencing it on Linux and<br>
on Windows with versions Pd 0.46 - 0.48.<br>
<br>
Roman <br>
<br>
On Fre, 2017-09-22 at 16:11 +0200, Johnny Mauser via Pd-list wrote:<br>
> I have the same behaviour in Ubuntu 16.04 and pd 0.46<br>
><br>
> The only workarround i found was to construct the gui in another<br>
> instance.<br>
><br>
> Am 22.09.2017 3:14 nachm. schrieb "Roman Haefeli" <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a><br>
> >:<br>
> Hey all<br>
><br>
> Apologies for a somewhat vague bug report about a hard to reproduce<br>
> issues (yeah, everybody loves those).<br>
><br>
> I tend to create instruments for netpd with lots of visual feeback<br>
> (song position in sequencer, triggered notes, automated values,<br>
> meters). Sometimes during sessions with rather many instruments, it<br>
> happens what I (only half-correctly) call a GUI freeze. Sliders,<br>
> number<br>
> atoms, symbol atoms, radios etc. stop visually reflecting any change.<br>
> They still do send new values through their outlet, but are not<br>
> updated<br>
> visually, neither when manually changed or when sending new values<br>
> through inlet or send symbol. When it happens, it affects all GUI<br>
> widgets of all patches the running Pd instance. It usually happens<br>
> after an error is printed to the Pd console:<br>
><br>
>  (Tcl) INVALID COMMAND NAME: invalid command name ".x88d5c68.c"<br>
>     while executing<br>
> ".x88d5c68.c delete curve8cc3d94"<br>
>     ("uplevel" body line 23)<br>
>     invoked from within<br>
> "uplevel #0 $docmds"<br>
><br>
><br>
> Interestingly, when I minimize a canvas and unminimize (or switch<br>
> desktop away and back) it again, it all widgets display the current<br>
> values, though live changes are still not updated. Also not all<br>
> properties of the GUI widgets are affected. Label texts, label fonts,<br>
> background, foreground and label colors, also cnv dimensions and<br>
> similar things are still updated. Or in other words: Those aspects<br>
> that<br>
> work both ways (GUI -> pd and pd -> GUI) are affected, while the<br>
> supplemental features of the widgets that can't be controlled by<br>
> mouse<br>
> (pd -> GUI only) are not affected. The situation persists until I<br>
> restart Pd. <br>
><br>
> That's again a vague statement, but I have the impression it got<br>
> slightly worse when switching from 0.47 to 0.48. I'm not able to<br>
> create<br>
> a simple patch that triggers the GUI freeze. However, I have saved<br>
> sessions that run reliably into this within minutes. <br>
><br>
> Thanks for any thoughts on this.<br>
><br>
> Roman<br>
> ______________________________<wbr>_________________<br>
> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/lis" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>lis</a><br>
> tinfo/pd-list<br>
><br>
><br>
> ______________________________<wbr>_________________<br>
> <a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
> UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/lis" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>lis</a><br>
> tinfo/pd-list<br>______________________________<wbr>_________________<br>
<a href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list<br>
UNSUBSCRIBE and account-management -> <a href="https://lists.puredata.info/listinfo/pd-list" rel="noreferrer" target="_blank">https://lists.puredata.info/<wbr>listinfo/pd-list</a><br>
<br></blockquote></div></div>