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