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/ listinfo/pd-list
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
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.
Best,
Ico
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
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
On Die, 2017-09-26 at 11:38 -0700, Miller Puckette wrote:
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. I cannot test as easily on Window as I can on Linux. I only have Windows as virtualized system and I run out of CPU a lot before I trigger the issues at hand. Is there a git branch containing the fix or some other access to the source? I could copy over the changed source files from the Windows build, if I know what changed.
Roman
Fix is in master on github...
https://github.com/pure-data/pure-dat
cheers Miller
On Wed, Sep 27, 2017 at 09:40:42PM +0200, Roman Haefeli wrote:
On Die, 2017-09-26 at 11:38 -0700, Miller Puckette wrote:
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. I cannot test as easily on Window as I can on Linux. I only have Windows as virtualized system and I run out of CPU a lot before I trigger the issues at hand. Is there a git branch containing the fix or some other access to the source? I could copy over the changed source files from the Windows build, if I know what changed.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mit, 2017-09-27 at 12:42 -0700, Miller Puckette wrote:
Fix is in master on github...
I was trying really hard to trigger the freeze, but wasn't able to. The most I got was a the GUI being stuck for a second, but it never froze for good. This is slightly exciting. Will see how to next session goes and will be much more excited if it stays freeze-less for 2-3 hours.
Thanks a lot <3
Roman
Ai, nice!
sounds exiting! I cannot test, because im such a linux newbie and tomorrow my show must run on the machine.
would be great if it has been fixed, im exited to try nexttime!
love,
-j-
Am 27.09.2017 um 22:37 schrieb Roman Haefeli reduzent@gmail.com:
On Mit, 2017-09-27 at 12:42 -0700, Miller Puckette wrote:
Fix is in master on github...
I was trying really hard to trigger the freeze, but wasn't able to. The most I got was a the GUI being stuck for a second, but it never froze for good. This is slightly exciting. Will see how to next session goes and will be much more excited if it stays freeze-less for 2-3 hours.
Thanks a lot <3
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On Mit, 2017-09-27 at 12:42 -0700, Miller Puckette wrote:
Fix is in master on github...
Update:
In three 3 hour sessions I experienced a freeze once. Two sessions went freeze-free. It could also be that I was impatient and the GUI would have continued working if I had waited a bit longer.
Definitely a huge improvement. Thanks again!
Roman
-
hi -
Ivica Bukvic -
Johnny Mauser
-
Miller Puckette -
Roman Haefeli