Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Without seeing the patch this may be tricky to diagnose. If I had to guess, I would say you are redundantly updating something too quickly.
FWIW, in pd-l2ork k12 mode every object is a gop abstraction with many having live gui components. Even with dozens of such abstractions (I've seen as many as 50ish) and high rate of metros on a measly netbook, there were no problems... On Dec 16, 2012 8:49 AM, "Ed Kelly" morph_2016@yahoo.co.uk wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/ _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input from GUI and other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() never gets called.
I've also seen a patch's GUI stop updating, but rather than bewail the fact that my GUI was dead, my immediate reactions was to be astonished that the sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
That's great! The hack seems to work really well.
I've also seen a patch's GUI stop updating, but rather than bewail the
fact that my GUI was dead, my immediate reactions was to be astonished that the sound was still working :)
...that's the best way a glitch could happen I suppose, but anything to reduce "PANIC!" moments while performing will improve my life a lot <:->
Ed
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as
it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I
find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since
the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of
externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
I've seen similar things, like with the patches that Porres submitted. It looks like what's happening is that when there are too many updates being sent, a lot of them get dropped. Its pretty easy to get 250k per second of Tcl code being sent to the GUI, so we're asking a lot of the Tcl parser and compiler. The solution is to reduce the amount of Tcl code that gets sent and also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input from GUI and other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() never gets called.
I've also seen a patch's GUI stop updating, but rather than bewail the fact that my GUI was dead, my immediate reactions was to be astonished that the sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s on every tick unless teh GUI itself is sending hundreds of messages per second down to Pd.
Reducing the average volume of trafic won't solve the underlying problem, it will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres submitted. It looks like what's happening is that when there are too many updates being sent, a lot of them get dropped. Its pretty easy to get 250k per second of Tcl code being sent to the GUI, so we're asking a lot of the Tcl parser and compiler. The solution is to reduce the amount of Tcl code that gets sent and also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input from GUI and other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() never gets called.
I've also seen a patch's GUI stop updating, but rather than bewail the fact that my GUI was dead, my immediate reactions was to be astonished that the sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Seems like there is multiple issues going on here. I've been working with Porres' Brane-e patch, where the array updates while recording in 0.42 but not in 0.43. It seems that in 0.43, scalar_vis only gets calls once when the recording starts, then again only after the recording has finished.
But now, in a bizarre twist, it has fixed itself in every Pd installed on my system. Before this problem used to happen every time with 0.43 vanilla and extended. Now it works everywhere, even on the binary packages, which I definitely didn't change.
When I was able to reproduce the Brane-e problem, changing sys_pollgui() didn't affect it either way.
.hc
On 12/17/2012 03:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s on every tick unless teh GUI itself is sending hundreds of messages per second down to Pd.
Reducing the average volume of trafic won't solve the underlying problem, it will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres submitted. It looks like what's happening is that when there are too many updates being sent, a lot of them get dropped. Its pretty easy to get 250k per second of Tcl code being sent to the GUI, so we're asking a lot of the Tcl parser and compiler. The solution is to reduce the amount of Tcl code that gets sent and also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input from GUI and other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() never gets called.
I've also seen a patch's GUI stop updating, but rather than bewail the fact that my GUI was dead, my immediate reactions was to be astonished that the sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s on every tick unless teh GUI itself is sending hundreds of messages per second down to Pd.
Reducing the average volume of trafic won't solve the underlying problem, it will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres submitted. It looks like what's happening is that when there are too many updates being sent, a lot of them get dropped. Its pretty easy to get 250k per second of Tcl code being sent to the GUI, so we're asking a lot of the Tcl parser and compiler. The solution is to reduce the amount of Tcl code that gets sent and also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input from GUI and other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() never gets called.
I've also seen a patch's GUI stop updating, but rather than bewail the fact that my GUI was dead, my immediate reactions was to be astonished that the sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hmmm... I'll have a look. Thanks for doing the heavy lifting on this one!
M
On Wed, Dec 19, 2012 at 09:39:02AM -0500, Hans-Christoph Steiner wrote:
I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s on every tick unless teh GUI itself is sending hundreds of messages per second down to Pd.
Reducing the average volume of trafic won't solve the underlying problem, it will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres submitted. It looks like what's happening is that when there are too many updates being sent, a lot of them get dropped. Its pretty easy to get 250k per second of Tcl code being sent to the GUI, so we're asking a lot of the Tcl parser and compiler. The solution is to reduce the amount of Tcl code that gets sent and also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input from GUI and other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() never gets called.
I've also seen a patch's GUI stop updating, but rather than bewail the fact that my GUI was dead, my immediate reactions was to be astonished that the sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Excellent, thanks! For what its worth, I tracked it down by using 'git bisect', a very handy tool. I customized makefile.mac since the build systems in git didn't always work.
.hc
On Dec 19, 2012, at 2:42 PM, Miller Puckette wrote:
Hmmm... I'll have a look. Thanks for doing the heavy lifting on this one!
M
On Wed, Dec 19, 2012 at 09:39:02AM -0500, Hans-Christoph Steiner wrote:
I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s on every tick unless teh GUI itself is sending hundreds of messages per second down to Pd.
Reducing the average volume of trafic won't solve the underlying problem, it will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres submitted. It looks like what's happening is that when there are too many updates being sent, a lot of them get dropped. Its pretty easy to get 250k per second of Tcl code being sent to the GUI, so we're asking a lot of the Tcl parser and compiler. The solution is to reduce the amount of Tcl code that gets sent and also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input from GUI and other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() never gets called.
I've also seen a patch's GUI stop updating, but rather than bewail the fact that my GUI was dead, my immediate reactions was to be astonished that the sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK, well in fact the problem was not arrays updating. It was all the other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per second down to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres
submitted. It
looks like what's happening is that when there are too many updates
being
sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
compiler. The solution is to reduce the amount of Tcl code that gets
sent and
also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
other FDs - isn't ever returning "idle" (zero) so
that sys_poll_togui() never
gets called.
I've also seen a patch's GUI stop updating, but rather than
bewail the fact
that my GUI was dead, my immediate reactions was to be astonished
that the
sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a
"recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance
time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It seems that there are a number of issues here:
GUI objects sending every update, regardless of change (fixed)
arrays stop updating on Mac OS X (pinpointed) I just tested this on Windows, and it looks like only Mac OS X is affected
all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui())
GUI objects sending updates to GUI as fast as they receive them even tho the screen will never update faster than every ~10ms.
some GUI updates send lots of raw Tcl code to be parsed, compiled, and run in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all the other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per second down to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres
submitted. It
looks like what's happening is that when there are too many updates
being
sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
compiler. The solution is to reduce the amount of Tcl code that gets
sent and
also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
other FDs - isn't ever returning "idle" (zero) so
that sys_poll_togui() never
gets called.
I've also seen a patch's GUI stop updating, but rather than
bewail the fact
that my GUI was dead, my immediate reactions was to be astonished
that the
sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a
"recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance
time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also commit the return (sys_domicrosleep(0, 1) || sys_poll_togui()) ---> + change as well (somehow I think it should never be necessary to do that but I'm realizing how little I understand Pd's scheduler.)
cheers M
On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote:
It seems that there are a number of issues here:
GUI objects sending every update, regardless of change (fixed)
arrays stop updating on Mac OS X (pinpointed) I just tested this on Windows, and it looks like only Mac OS X is affected
all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui())
GUI objects sending updates to GUI as fast as they receive them even tho the screen will never update faster than every ~10ms.
some GUI updates send lots of raw Tcl code to be parsed, compiled, and run in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all the other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that Porres reported. I think its a totally different problem related to Pd-0.43's new portaudio implementation. It does not affect GNU/Linux, which doesn't use protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
Ed, if part of your problem is arrays that stop updating and you're running on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i mean, I don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per second down to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner wrote:
I've seen similar things, like with the patches that Porres
submitted. It
looks like what's happening is that when there are too many updates
being
sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
compiler. The solution is to reduce the amount of Tcl code that gets
sent and
also use Tcl procs to handle bigger chunks of stuff so that we can take advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote:
This is just a guess... in s_inter.c, try replacing:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) || sys_poll_togui()); }
with:
int sys_pollgui(void) { return (sys_domicrosleep(0, 1) + sys_poll_togui()); }
It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
other FDs - isn't ever returning "idle" (zero) so
that sys_poll_togui() never
gets called.
I've also seen a patch's GUI stop updating, but rather than
bewail the fact
that my GUI was dead, my immediate reactions was to be astonished
that the
sound was still working :)
Miller
On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote: > Hi List, > > I'm not going to say whether this is a
"recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
> > I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
> > I'm also making less GUI intensive versions for performance
time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
> > System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4, lots of externals compiled and loaded.
> > Warm wishes, > Ed > > Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
> _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Miller,
Pd-l2ork has this fix since your original post on the PD list and I've yet to see any regressions. Many thanks for the suggestion. That said, I've yet to understand the logic behind it ;-).
P.S. I also discovered quite a while ago that netreceive had a tendency to freeze GUI permanently, likely due to asynchronous message processing. I fixed this by enqueuing its messages and syncing them with the main PD loop. This has been a part of pd-l2ork for over a year without a single GUI freeze. That said, I did encounter situations where high traffic would freeze GUI temporarily and then resume (albeit running now behind the actual timeline as the GUI would simply resume as if nothing happened, rather than processing all calls that have piled up since the temporary freeze happened and for which time has already passed, e.g. having a timer in a score that freezes and then resumes from the moment it was stuck rather than adding seconds lost since such calls should've been enqueued while the freeze was in effect). This may have been in part due to atom cpus being taxed to their very limits. I've yet to see whether your proposed fix resolves the lingering issue.
HTH
Best wishes,
Ico On Dec 20, 2012 7:02 PM, "Miller Puckette" msp@ucsd.edu wrote:
OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also commit the return (sys_domicrosleep(0, 1) || sys_poll_togui()) ---> + change as well (somehow I think it should never be necessary to do that but I'm realizing how little I understand Pd's scheduler.)
cheers M
On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote:
It seems that there are a number of issues here:
GUI objects sending every update, regardless of change (fixed)
arrays stop updating on Mac OS X (pinpointed) I just tested this on
Windows, and it looks like only Mac OS X is affected
all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui())
GUI objects sending updates to GUI as fast as they receive them even
tho the screen will never update faster than every ~10ms.
- some GUI updates send lots of raw Tcl code to be parsed, compiled, and
run in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all the
other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually
dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that
Porres
reported. I think its a totally different problem related to
Pd-0.43's new
portaudio implementation. It does not affect GNU/Linux, which
doesn't use
protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
Ed, if part of your problem is arrays that stop updating and you're
running
on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i
mean, I
don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per
second down
to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner
wrote:
I've seen similar things, like with the patches that Porres
submitted. It
looks like what's happening is that when there are too many updates
being
sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
compiler. The solution is to reduce the amount of Tcl code that
gets
sent and
also use Tcl procs to handle bigger chunks of stuff so that we can
take
advantage of Tcl caching parsed and compiled procs.
.hc
On 12/16/2012 01:47 PM, Miller Puckette wrote: > This is just a guess... in s_inter.c, try replacing: > > int sys_pollgui(void) > { > return (sys_domicrosleep(0, 1) || sys_poll_togui()); > } > > with: > > int sys_pollgui(void) > { > return (sys_domicrosleep(0, 1) + sys_poll_togui()); > } > > It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
> other FDs - isn't ever returning "idle" (zero) so
that sys_poll_togui() never
> gets called. > > I've also seen a patch's GUI stop updating, but rather than
bewail the fact
> that my GUI was dead, my immediate reactions was to be astonished
that the
> sound was still working :) > > Miller > > On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote: >> Hi List, >> >> I'm not going to say whether this is a
"recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
>> >> I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I find the following problem occurs. There comes a point
where the GUI
objects stop responding in a patch when it is reloaded. I am
wondering if there
is a specific limit to GUI objects that could be changed. I think Pd
is making
some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to
know
how or if it is possible to control this process from within Pd, or
by setting
flags on the command line.
>> >> I'm also making less GUI intensive versions for performance
time, since the really big GUI patches are often pattern-sequencers
which I will
not want to program when I am performing. Example patch enclosed to
give you an
idea. The really GUI-intensive objects are the trackers, especially
quadtracker
(which I think has pushed the GUI of Pd patches about as far as I can
go now).
>> >> System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4, lots of externals compiled and loaded.
>> >> Warm wishes, >> Ed >> >> Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
>> http://sharktracks.co.uk/ > > >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
> > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
My worry is, I'm not sure if there's still a problem out there that the || -. + change fixes. Maybe I should try to cook up a formal definition of what "working correctly" should consist of :)
M
On Thu, Dec 20, 2012 at 09:30:40PM -0500, Ivica Bukvic wrote:
Miller,
Pd-l2ork has this fix since your original post on the PD list and I've yet to see any regressions. Many thanks for the suggestion. That said, I've yet to understand the logic behind it ;-).
P.S. I also discovered quite a while ago that netreceive had a tendency to freeze GUI permanently, likely due to asynchronous message processing. I fixed this by enqueuing its messages and syncing them with the main PD loop. This has been a part of pd-l2ork for over a year without a single GUI freeze. That said, I did encounter situations where high traffic would freeze GUI temporarily and then resume (albeit running now behind the actual timeline as the GUI would simply resume as if nothing happened, rather than processing all calls that have piled up since the temporary freeze happened and for which time has already passed, e.g. having a timer in a score that freezes and then resumes from the moment it was stuck rather than adding seconds lost since such calls should've been enqueued while the freeze was in effect). This may have been in part due to atom cpus being taxed to their very limits. I've yet to see whether your proposed fix resolves the lingering issue.
HTH
Best wishes,
Ico On Dec 20, 2012 7:02 PM, "Miller Puckette" msp@ucsd.edu wrote:
OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also commit the return (sys_domicrosleep(0, 1) || sys_poll_togui()) ---> + change as well (somehow I think it should never be necessary to do that but I'm realizing how little I understand Pd's scheduler.)
cheers M
On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner wrote:
It seems that there are a number of issues here:
GUI objects sending every update, regardless of change (fixed)
arrays stop updating on Mac OS X (pinpointed) I just tested this on
Windows, and it looks like only Mac OS X is affected
all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui())
GUI objects sending updates to GUI as fast as they receive them even
tho the screen will never update faster than every ~10ms.
- some GUI updates send lots of raw Tcl code to be parsed, compiled, and
run in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all the
other GUI objects (sliders, mknob, num2 etc) that would freeze, and this is running on GNU/Linux. This was a real problem, since I could change them with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are actually
dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem that
Porres
reported. I think its a totally different problem related to
Pd-0.43's new
portaudio implementation. It does not affect GNU/Linux, which
doesn't use
protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
Ed, if part of your problem is arrays that stop updating and you're
running
on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
OK... except that I don't know why this works yet... by which i
mean, I
don't think it's possible that sys_domicrosleep(0 is returning 1s
on every
tick unless teh GUI itself is sending hundreds of messages per
second down
to Pd.
Reducing the average volume of trafic won't solve the underlying
problem, it
will just make it harder to recreate it :)
M
On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner
wrote:
> > I've seen similar things, like with the patches that Porres
submitted. It
> looks like what's happening is that when there are too many updates
being
> sent, a lot of them get dropped. Its pretty easy to get 250k per
second of
> Tcl code being sent to the GUI, so we're asking a lot of the Tcl
parser and
> compiler. The solution is to reduce the amount of Tcl code that
gets
sent and
> also use Tcl procs to handle bigger chunks of stuff so that we can
take
> advantage of Tcl caching parsed and compiled procs. > > .hc > > On 12/16/2012 01:47 PM, Miller Puckette wrote: >> This is just a guess... in s_inter.c, try replacing: >> >> int sys_pollgui(void) >> { >> return (sys_domicrosleep(0, 1) || sys_poll_togui()); >> } >> >> with: >> >> int sys_pollgui(void) >> { >> return (sys_domicrosleep(0, 1) + sys_poll_togui()); >> } >> >> It's possible that sys_domicrosleep(0 - which polls for input
from GUI and
>> other FDs - isn't ever returning "idle" (zero) so
that sys_poll_togui() never
>> gets called. >> >> I've also seen a patch's GUI stop updating, but rather than
bewail the fact
>> that my GUI was dead, my immediate reactions was to be astonished
that the
>> sound was still working :) >> >> Miller >> >> On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote: >>> Hi List, >>> >>> I'm not going to say whether this is a
"recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
>>> >>> I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I find the following problem occurs. There comes a point
where the GUI
objects stop responding in a patch when it is reloaded. I am
wondering if there
is a specific limit to GUI objects that could be changed. I think Pd
is making
some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to
know
how or if it is possible to control this process from within Pd, or
by setting
flags on the command line.
>>> >>> I'm also making less GUI intensive versions for performance
time, since the really big GUI patches are often pattern-sequencers
which I will
not want to program when I am performing. Example patch enclosed to
give you an
idea. The really GUI-intensive objects are the trackers, especially
quadtracker
(which I think has pushed the GUI of Pd patches about as far as I can
go now).
>>> >>> System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4, lots of externals compiled and loaded.
>>> >>> Warm wishes, >>> Ed >>> >>> Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
>>> http://sharktracks.co.uk/ >> >> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
>> > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in heavy traffic situations gets visibly sluggish and falls behind, so to say. This still leaves the only notable difference between pd-l2ork and pd that has so far proven pd-l2ork resistant to the problems encountered below and those have to do with the way how pd-l2ork has altered both netsend/netreceive and also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues...
-----Original Message----- From: Miller Puckette [mailto:msp@ucsd.edu] Sent: Thursday, December 20, 2012 11:46 PM To: Ivica Bukvic Cc: pd-list@iem.at Subject: Re: [PD] GUI overload
My worry is, I'm not sure if there's still a problem out there that the || -. + change fixes. Maybe I should try to cook up a formal definition of what "working correctly" should consist of :)
M
On Thu, Dec 20, 2012 at 09:30:40PM -0500, Ivica Bukvic wrote:
Miller,
Pd-l2ork has this fix since your original post on the PD list and I've
yet
to see any regressions. Many thanks for the suggestion. That said, I've
yet
to understand the logic behind it ;-).
P.S. I also discovered quite a while ago that netreceive had a tendency
to
freeze GUI permanently, likely due to asynchronous message processing. I fixed this by enqueuing its messages and syncing them with the main PD loop. This has been a part of pd-l2ork for over a year without a single
GUI
freeze. That said, I did encounter situations where high traffic would freeze GUI temporarily and then resume (albeit running now behind the actual timeline as the GUI would simply resume as if nothing happened, rather than processing all calls that have piled up since the temporary freeze happened and for which time has already passed, e.g. having a
timer
in a score that freezes and then resumes from the moment it was stuck rather than adding seconds lost since such calls should've been enqueued while the freeze was in effect). This may have been in part due to atom cpus being taxed to their very limits. I've yet to see whether your proposed fix resolves the lingering issue.
HTH
Best wishes,
Ico On Dec 20, 2012 7:02 PM, "Miller Puckette" msp@ucsd.edu wrote:
OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also
commit
the return (sys_domicrosleep(0, 1) || sys_poll_togui()) ---> + change as well (somehow I think it should never be necessary to do that but
I'm
realizing how little I understand Pd's scheduler.)
cheers M
On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner
wrote:
It seems that there are a number of issues here:
GUI objects sending every update, regardless of change (fixed)
arrays stop updating on Mac OS X (pinpointed) I just tested this
on
Windows, and it looks like only Mac OS X is affected
all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui())
GUI objects sending updates to GUI as fast as they receive them
even
tho the screen will never update faster than every ~10ms.
- some GUI updates send lots of raw Tcl code to be parsed, compiled,
and
run in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all
the
other GUI objects (sliders, mknob, num2 etc) that would freeze, and
this
is
running on GNU/Linux. This was a real problem, since I could change
them
with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are
actually
dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
Ed
I tracked down the commit that seems to be causing the problem
that
Porres
reported. I think its a totally different problem related to
Pd-0.43's new
portaudio implementation. It does not affect GNU/Linux, which
doesn't use
protaudio. I haven't tested it on Windows.
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55... 6&atid=478070
Ed, if part of your problem is arrays that stop updating and
you're
running
on Mac OS X or maybe Windows, this might also be affecting you.
.hc
On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote:
> OK... except that I don't know why this works yet... by which i
mean, I
> don't think it's possible that sys_domicrosleep(0 is returning
1s
on every > tick unless teh GUI itself is sending hundreds of messages per
second down
> to Pd. > > Reducing the average volume of trafic won't solve the underlying problem, it > will just make it harder to recreate it :) > > M > > On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner
wrote:
>> >> I've seen similar things, like with the patches that Porres submitted. It >> looks like what's happening is that when there are too many
updates
being >> sent, a lot of them get dropped. Its pretty easy to get 250k
per
second of >> Tcl code being sent to the GUI, so we're asking a lot of the
Tcl
parser and >> compiler. The solution is to reduce the amount of Tcl code
that
gets
sent and >> also use Tcl procs to handle bigger chunks of stuff so that we
can
take
>> advantage of Tcl caching parsed and compiled procs. >> >> .hc >> >> On 12/16/2012 01:47 PM, Miller Puckette wrote: >>> This is just a guess... in s_inter.c, try replacing: >>> >>> int sys_pollgui(void) >>> { >>> return (sys_domicrosleep(0, 1) || sys_poll_togui()); >>> } >>> >>> with: >>> >>> int sys_pollgui(void) >>> { >>> return (sys_domicrosleep(0, 1) + sys_poll_togui()); >>> } >>> >>> It's possible that sys_domicrosleep(0 - which polls for input from GUI and >>> other FDs - isn't ever returning "idle" (zero) so that sys_poll_togui() never >>> gets called. >>> >>> I've also seen a patch's GUI stop updating, but rather than bewail the fact >>> that my GUI was dead, my immediate reactions was to be
astonished
that the >>> sound was still working :) >>> >>> Miller >>> >>> On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote: >>>> Hi List, >>>> >>>> I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of
the
GUI has affected it... >>>> >>>> I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a
point
where the GUI
objects stop responding in a patch when it is reloaded. I am
wondering if there
is a specific limit to GUI objects that could be changed. I think
Pd
is making
some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like
to
know
how or if it is possible to control this process from within Pd,
or
by setting
flags on the command line. >>>> >>>> I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often
pattern-sequencers
which I will
not want to program when I am performing. Example patch
enclosed to
give you an
idea. The really GUI-intensive objects are the trackers,
especially
quadtracker
(which I think has pushed the GUI of Pd patches about as far as I
can
go now).
>>>> >>>> System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded. >>>> >>>> Warm wishes, >>>> Ed >>>> >>>> Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! >>>> http://sharktracks.co.uk/ >>> >>> >>>> _______________________________________________ >>>> Pd-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >>> >>> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >>> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
I don't quite understand. Are you saying that this || to + change does help or does not help?
.hc
On 02/14/2013 09:27 PM, Ivica Ico Bukvic wrote:
OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in heavy traffic situations gets visibly sluggish and falls behind, so to say. This still leaves the only notable difference between pd-l2ork and pd that has so far proven pd-l2ork resistant to the problems encountered below and those have to do with the way how pd-l2ork has altered both netsend/netreceive and also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues...
-----Original Message----- From: Miller Puckette [mailto:msp@ucsd.edu] Sent: Thursday, December 20, 2012 11:46 PM To: Ivica Bukvic Cc: pd-list@iem.at Subject: Re: [PD] GUI overload
My worry is, I'm not sure if there's still a problem out there that the || -. + change fixes. Maybe I should try to cook up a formal definition of what "working correctly" should consist of :)
M
On Thu, Dec 20, 2012 at 09:30:40PM -0500, Ivica Bukvic wrote:
Miller,
Pd-l2ork has this fix since your original post on the PD list and I've
yet
to see any regressions. Many thanks for the suggestion. That said, I've
yet
to understand the logic behind it ;-).
P.S. I also discovered quite a while ago that netreceive had a tendency
to
freeze GUI permanently, likely due to asynchronous message processing. I fixed this by enqueuing its messages and syncing them with the main PD loop. This has been a part of pd-l2ork for over a year without a single
GUI
freeze. That said, I did encounter situations where high traffic would freeze GUI temporarily and then resume (albeit running now behind the actual timeline as the GUI would simply resume as if nothing happened, rather than processing all calls that have piled up since the temporary freeze happened and for which time has already passed, e.g. having a
timer
in a score that freezes and then resumes from the moment it was stuck rather than adding seconds lost since such calls should've been enqueued while the freeze was in effect). This may have been in part due to atom cpus being taxed to their very limits. I've yet to see whether your proposed fix resolves the lingering issue.
HTH
Best wishes,
Ico On Dec 20, 2012 7:02 PM, "Miller Puckette" msp@ucsd.edu wrote:
OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also
commit
the return (sys_domicrosleep(0, 1) || sys_poll_togui()) ---> + change as well (somehow I think it should never be necessary to do that but
I'm
realizing how little I understand Pd's scheduler.)
cheers M
On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner
wrote:
It seems that there are a number of issues here:
GUI objects sending every update, regardless of change (fixed)
arrays stop updating on Mac OS X (pinpointed) I just tested this
on
Windows, and it looks like only Mac OS X is affected
all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui())
GUI objects sending updates to GUI as fast as they receive them
even
tho the screen will never update faster than every ~10ms.
- some GUI updates send lots of raw Tcl code to be parsed, compiled,
and
run in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
OK, well in fact the problem was not arrays updating. It was all
the
other GUI objects (sliders, mknob, num2 etc) that would freeze, and
this
is
running on GNU/Linux. This was a real problem, since I could change
them
with the mouse, but the results of the change were not shown (e.g. the pattern-number in one of my sequencers).
Changing sys_pollgui() did fix this, so perhaps what we are
actually
dealing with is two separate issues, one concerning arrays and another concerning the rest of the GUI.
Ed >
> I tracked down the commit that seems to be causing the problem
that
Porres
> reported. I think its a totally different problem related to
Pd-0.43's new
> portaudio implementation. It does not affect GNU/Linux, which
doesn't use
> protaudio. I haven't tested it on Windows. > >
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55... 6&atid=478070
> > Ed, if part of your problem is arrays that stop updating and
you're
running
> on Mac OS X or maybe Windows, this might also be affecting you. > > .hc > > On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote: > >> OK... except that I don't know why this works yet... by which i
mean, I
>> don't think it's possible that sys_domicrosleep(0 is returning
1s
> on every >> tick unless teh GUI itself is sending hundreds of messages per
second down
>> to Pd. >> >> Reducing the average volume of trafic won't solve the underlying > problem, it >> will just make it harder to recreate it :) >> >> M >> >> On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner
wrote:
>>> >>> I've seen similar things, like with the patches that Porres > submitted. It >>> looks like what's happening is that when there are too many
updates
> being >>> sent, a lot of them get dropped. Its pretty easy to get 250k
per
> second of >>> Tcl code being sent to the GUI, so we're asking a lot of the
Tcl
> parser and >>> compiler. The solution is to reduce the amount of Tcl code
that
gets
> sent and >>> also use Tcl procs to handle bigger chunks of stuff so that we
can
take
>>> advantage of Tcl caching parsed and compiled procs. >>> >>> .hc >>> >>> On 12/16/2012 01:47 PM, Miller Puckette wrote: >>>> This is just a guess... in s_inter.c, try replacing: >>>> >>>> int sys_pollgui(void) >>>> { >>>> return (sys_domicrosleep(0, 1) || sys_poll_togui()); >>>> } >>>> >>>> with: >>>> >>>> int sys_pollgui(void) >>>> { >>>> return (sys_domicrosleep(0, 1) + sys_poll_togui()); >>>> } >>>> >>>> It's possible that sys_domicrosleep(0 - which polls for input > from GUI and >>>> other FDs - isn't ever returning "idle" (zero) so > that sys_poll_togui() never >>>> gets called. >>>> >>>> I've also seen a patch's GUI stop updating, but rather than > bewail the fact >>>> that my GUI was dead, my immediate reactions was to be
astonished
> that the >>>> sound was still working :) >>>> >>>> Miller >>>> >>>> On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote: >>>>> Hi List, >>>>> >>>>> I'm not going to say whether this is a > "recurrent" problem as it's hard to say whether the rewrite of
the
> GUI has affected it... >>>>> >>>>> I'm using a lot of abstractions with larger GOP or non-GOP > GUIs, and I find the following problem occurs. There comes a
point
where the GUI
> objects stop responding in a patch when it is reloaded. I am
wondering if there
> is a specific limit to GUI objects that could be changed. I think
Pd
is making
> some kind of decision that "there's too much of this stuff - I'm > gonna prioritize the audio and not worry about it" and I'd like
to
know
> how or if it is possible to control this process from within Pd,
or
by setting
> flags on the command line. >>>>> >>>>> I'm also making less GUI intensive versions for performance > time, since the really big GUI patches are often
pattern-sequencers
which I will
> not want to program when I am performing. Example patch
enclosed to
give you an
> idea. The really GUI-intensive objects are the trackers,
especially
quadtracker
> (which I think has pushed the GUI of Pd patches about as far as I
can
go now).
>>>>> >>>>> System: quad core i5 PC running Ubuntu (10.04 Lucid), > Pd-0.43-4, lots of externals compiled and loaded. >>>>> >>>>> Warm wishes, >>>>> Ed >>>>> >>>>> Gemnotes-0.2: Live music notation for Pure Data, now with > dynamics! >>>>> http://sharktracks.co.uk/ >>>> >>>> >>>>> _______________________________________________ >>>>> Pd-list@iem.at mailing list >>>>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >>>> >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >>>> >>> >>> _______________________________________________ >>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
It makes things worse in pd-l2ork. Pd-l2ork did not need it (AFAICT) in the first place since I had the netsend/receive fixed but I tried it anyhow just to make sure and my conclusion is it makes things more sluggish gui-wise.
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Hans-Christoph Steiner Sent: Thursday, February 14, 2013 10:07 PM To: pd-list@iem.at Subject: Re: [PD] GUI overload
I don't quite understand. Are you saying that this || to + change does
help
or does not help?
.hc
On 02/14/2013 09:27 PM, Ivica Ico Bukvic wrote:
OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in
heavy
traffic situations gets visibly sluggish and falls behind, so to say.
This
still leaves the only notable difference between pd-l2ork and pd that
has so
far proven pd-l2ork resistant to the problems encountered below and
those
have to do with the way how pd-l2ork has altered both
netsend/netreceive and
also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues...
-----Original Message----- From: Miller Puckette [mailto:msp@ucsd.edu] Sent: Thursday, December 20, 2012 11:46 PM To: Ivica Bukvic Cc: pd-list@iem.at Subject: Re: [PD] GUI overload
My worry is, I'm not sure if there's still a problem out there that the || -. + change fixes. Maybe I should try to cook up a formal
definition
of what "working correctly" should consist of :)
M
On Thu, Dec 20, 2012 at 09:30:40PM -0500, Ivica Bukvic wrote:
Miller,
Pd-l2ork has this fix since your original post on the PD list and I've
yet
to see any regressions. Many thanks for the suggestion. That said,
I've
yet
to understand the logic behind it ;-).
P.S. I also discovered quite a while ago that netreceive had a
tendency
to
freeze GUI permanently, likely due to asynchronous message
processing. I
fixed this by enqueuing its messages and syncing them with the main PD loop. This has been a part of pd-l2ork for over a year without a
single
GUI
freeze. That said, I did encounter situations where high traffic would freeze GUI temporarily and then resume (albeit running now behind the actual timeline as the GUI would simply resume as if nothing happened, rather than processing all calls that have piled up since the
temporary
freeze happened and for which time has already passed, e.g. having a
timer
in a score that freezes and then resumes from the moment it was stuck rather than adding seconds lost since such calls should've been
enqueued
while the freeze was in effect). This may have been in part due to
atom
cpus being taxed to their very limits. I've yet to see whether your proposed fix resolves the lingering issue.
HTH
Best wishes,
Ico On Dec 20, 2012 7:02 PM, "Miller Puckette" msp@ucsd.edu wrote:
OK... I've pushed a change that seems to have fixed the arrays-atop-updating problem (at lest in the Brane example). Not sure if I should also
commit
the return (sys_domicrosleep(0, 1) || sys_poll_togui()) ---> + change as well (somehow I think it should never be necessary to do that but
I'm
realizing how little I understand Pd's scheduler.)
cheers M
On Thu, Dec 20, 2012 at 12:17:35PM -0500, Hans-Christoph Steiner
wrote:
It seems that there are a number of issues here:
GUI objects sending every update, regardless of change (fixed)
arrays stop updating on Mac OS X (pinpointed) I just tested this
on
Windows, and it looks like only Mac OS X is affected
all GUI activity stopping related to: return (sys_domicrosleep(0, 1) || sys_poll_togui())
GUI objects sending updates to GUI as fast as they receive them
even
tho the screen will never update faster than every ~10ms.
- some GUI updates send lots of raw Tcl code to be parsed, compiled,
and
run in realtime
.hc
On Dec 20, 2012, at 5:54 AM, Ed Kelly wrote:
> OK, well in fact the problem was not arrays updating. It was all
the
other GUI objects (sliders, mknob, num2 etc) that would freeze, and
this
is
running on GNU/Linux. This was a real problem, since I could change
them
with the mouse, but the results of the change were not shown (e.g.
the
pattern-number in one of my sequencers).
> > Changing sys_pollgui() did fix this, so perhaps what we are
actually
dealing with is two separate issues, one concerning arrays and
another
concerning the rest of the GUI.
> > Ed >> > >> I tracked down the commit that seems to be causing the problem
that
Porres
>> reported. I think its a totally different problem related to
Pd-0.43's new
>> portaudio implementation. It does not affect GNU/Linux, which
doesn't use
>> protaudio. I haven't tested it on Windows. >> >>
https://sourceforge.net/tracker/?func=detail&aid=3573542&group_id=55...
6&atid=478070
>> >> Ed, if part of your problem is arrays that stop updating and
you're
running
>> on Mac OS X or maybe Windows, this might also be affecting you. >> >> .hc >> >> On Dec 17, 2012, at 3:12 PM, Miller Puckette wrote: >> >>> OK... except that I don't know why this works yet... by which i
mean, I
>>> don't think it's possible that sys_domicrosleep(0 is returning
1s
>> on every >>> tick unless teh GUI itself is sending hundreds of messages per
second down
>>> to Pd. >>> >>> Reducing the average volume of trafic won't solve the underlying >> problem, it >>> will just make it harder to recreate it :) >>> >>> M >>> >>> On Sun, Dec 16, 2012 at 08:00:31PM -0500, Hans-Christoph Steiner
wrote:
>>>> >>>> I've seen similar things, like with the patches that Porres >> submitted. It >>>> looks like what's happening is that when there are too many
updates
>> being >>>> sent, a lot of them get dropped. Its pretty easy to get 250k
per
>> second of >>>> Tcl code being sent to the GUI, so we're asking a lot of the
Tcl
>> parser and >>>> compiler. The solution is to reduce the amount of Tcl code
that
gets
>> sent and >>>> also use Tcl procs to handle bigger chunks of stuff so that we
can
take
>>>> advantage of Tcl caching parsed and compiled procs. >>>> >>>> .hc >>>> >>>> On 12/16/2012 01:47 PM, Miller Puckette wrote: >>>>> This is just a guess... in s_inter.c, try replacing: >>>>> >>>>> int sys_pollgui(void) >>>>> { >>>>> return (sys_domicrosleep(0, 1) || sys_poll_togui()); >>>>> } >>>>> >>>>> with: >>>>> >>>>> int sys_pollgui(void) >>>>> { >>>>> return (sys_domicrosleep(0, 1) + sys_poll_togui()); >>>>> } >>>>> >>>>> It's possible that sys_domicrosleep(0 - which polls for input >> from GUI and >>>>> other FDs - isn't ever returning "idle" (zero) so >> that sys_poll_togui() never >>>>> gets called. >>>>> >>>>> I've also seen a patch's GUI stop updating, but rather than >> bewail the fact >>>>> that my GUI was dead, my immediate reactions was to be
astonished
>> that the >>>>> sound was still working :) >>>>> >>>>> Miller >>>>> >>>>> On Sun, Dec 16, 2012 at 01:47:43PM +0000, Ed Kelly wrote: >>>>>> Hi List, >>>>>> >>>>>> I'm not going to say whether this is a >> "recurrent" problem as it's hard to say whether the rewrite of
the
>> GUI has affected it... >>>>>> >>>>>> I'm using a lot of abstractions with larger GOP or non-GOP >> GUIs, and I find the following problem occurs. There comes a
point
where the GUI
>> objects stop responding in a patch when it is reloaded. I am
wondering if there
>> is a specific limit to GUI objects that could be changed. I think
Pd
is making
>> some kind of decision that "there's too much of this stuff - I'm >> gonna prioritize the audio and not worry about it" and I'd like
to
know
>> how or if it is possible to control this process from within Pd,
or
by setting
>> flags on the command line. >>>>>> >>>>>> I'm also making less GUI intensive versions for performance >> time, since the really big GUI patches are often
pattern-sequencers
which I will
>> not want to program when I am performing. Example patch
enclosed to
give you an
>> idea. The really GUI-intensive objects are the trackers,
especially
quadtracker
>> (which I think has pushed the GUI of Pd patches about as far as I
can
go now).
>>>>>> >>>>>> System: quad core i5 PC running Ubuntu (10.04 Lucid), >> Pd-0.43-4, lots of externals compiled and loaded. >>>>>> >>>>>> Warm wishes, >>>>>> Ed >>>>>> >>>>>> Gemnotes-0.2: Live music notation for Pure Data, now with >> dynamics! >>>>>> http://sharktracks.co.uk/ >>>>> >>>>> >>>>>> _______________________________________________ >>>>>> Pd-list@iem.at mailing list >>>>>> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pd-list@iem.at mailing list >>>>> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >>>>> >>>> >>>> _______________________________________________ >>>> Pd-list@iem.at mailing list >>>> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Ivica Ico Bukvic ico@vt.edu To: 'Miller Puckette' msp@ucsd.edu Cc: pd-list@iem.at Sent: Thursday, February 14, 2013 9:27 PM Subject: Re: [PD] GUI overload
OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in heavy traffic situations gets visibly sluggish and falls behind, so to say. This still leaves the only notable difference between pd-l2ork and pd that has so far proven pd-l2ork resistant to the problems encountered below and those have to do with the way how pd-l2ork has altered both netsend/netreceive and also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues...
Why is it disis_netsend/receive and not simply a fixed netsend/receive? Did you change the interface in some way?
-Jonathan
OK, so I had several L2Ork rehearsals on new machines with this patch applied and I can confirm that this is actually a regression. GUI in
heavy
traffic situations gets visibly sluggish and falls behind, so to say.
This
still leaves the only notable difference between pd-l2ork and pd that
has so
far proven pd-l2ork resistant to the problems encountered below and
those
have to do with the way how pd-l2ork has altered both
netsend/netreceive and
also provided its own disis_netsend/receive externals that have been reported before on this list to have fixed similar gui freeze issues...
Why is it disis_netsend/receive and not simply a fixed netsend/receive?
Did
you change the interface in some way?
-Jonathan
Those have additional features (e.g. UDP broadcast, obviously operation without gui hiccups, as well as enqueing messages and dumping them all at once) that I implemented as separate externals before forking pd-l2ork so I did it in a way that did not mess with the core pd. Since then, I fixed netsend/receive in the core part of Pd as well but kept those for backwards compatibility purposes unaltered.
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob] that make them only send the GUI updates when something actually has changed. This can greatly reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of Pd-extended and see if you still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later Ubuntu versions to run on my new and old machines with no success, so I compiled the source code of Pd-extended 0.43 (2012-12-28 build). All was fine in linux_make/, then I tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd
/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
test -z "" || (
install -p -m 644 /home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp &&
)
/bin/sh: Syntax error: ")" unexpected
make[2]: *** [libdir_install] Error 2
? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 Subject: Re: [PD] GUI overload
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob] that make them only send the GUI updates when something actually has changed. This can greatly reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of Pd-extended and see if you still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as
it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I
find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since
the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of
externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Have you tried using the Pd-extended PPA, there is a Lucid package there:
https://launchpad.net/~eighthave/+archive/pd-extended
sudo add-apt-repository ppa:eighthave/pd-extended
.hc
On Jan 4, 2013, at 6:15 PM, Ed Kelly wrote:
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later Ubuntu versions to run on my new and old machines with no success, so I compiled the source code of Pd-extended 0.43 (2012-12-28 build). All was fine in linux_make/, then I tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd
/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp test -z "" || (
install -p -m 644 /home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp &&
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 Subject: Re: [PD] GUI overload
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob] that make them only send the GUI updates when something actually has changed. This can greatly reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of Pd-extended and see if you still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as
it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I
find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since
the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of
externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Oooh, aargh, exactly the same!
San Diego (Houston) we have a problem...Miller's sys_pollgui() fix is the only one I found that works, and perhaps we don't know why it works, but it works for me. Bear in mind I have 32x64+256=2304 GUI objects to update when the pattern changes on my sequencer, but I'm not entirely convinced that is the whole problem. The version I sent you (with all those GUI updates) worked fine it turned out, but the version I made of the sequencer to try to counteract this (with no GUI updates) - the performance patch with that still had the problem.
Since I now have both Pd versions - hacked vanilla and extended - is there any test I can carry out to determine what the issue might be?
Ed Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ed Kelly morph_2016@yahoo.co.uk Cc: "pd-list@iem.at" pd-list@iem.at Sent: Saturday, 5 January 2013, 0:08 Subject: Re: [PD] GUI overload
Have you tried using the Pd-extended PPA, there is a Lucid package there:
https://launchpad.net/~eighthave/+archive/pd-extended
sudo add-apt-repository ppa:eighthave/pd-extended
.hc
On Jan 4, 2013, at 6:15 PM, Ed Kelly wrote:
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later Ubuntu
versions to run on my new and old machines with no success, so I compiled the source code of Pd-extended 0.43 (2012-12-28 build). All was fine in linux_make/, then I tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd \
/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
test -z "" || (
install -p -m 644/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp && \
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2
? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 Subject: Re: [PD] GUI overload
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob] that make
them only
send the GUI updates when something actually has changed. This can
greatly
reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of Pd-extended and see
if you
still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent"
problem as
it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I
find the following problem occurs. There comes a point where the GUI
objects
stop responding in a patch when it is reloaded. I am wondering if there
is a
specific limit to GUI objects that could be changed. I think Pd is
making some
kind of decision that "there's too much of this stuff -
I'm gonna
prioritize the audio and not worry about it" and I'd like to
know how
or if it is possible to control this process from within Pd, or by
setting flags
on the command line.
I'm also making less GUI intensive versions for performance
time, since
the really big GUI patches are often pattern-sequencers which I will
not want to
program when I am performing. Example patch enclosed to give you an
idea. The
really GUI-intensive objects are the trackers, especially quadtracker
(which I
think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4,
lots of
externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
So now a question for me is - should I change || to + in the 0.44 release? My first impulse is to hold off since I can't be sure it won't affect scheduling in some other unknown way - after al if it makes one thing happen faster it presumably makes something else happen slower.
I'm hoping to make 0.44 official this weekend :)
M
On Sat, Jan 05, 2013 at 01:07:44AM +0000, Ed Kelly wrote:
Oooh, aargh, exactly the same!
San Diego (Houston) we have a problem...Miller's sys_pollgui() fix is the only one I found that works, and perhaps we don't know why it works, but it works for me. Bear in mind I have 32x64+256=2304 GUI objects to update when the pattern changes on my sequencer, but I'm not entirely convinced that is the whole problem. The version I sent you (with all those GUI updates) worked fine it turned out, but the version I made of the sequencer to try to counteract this (with no GUI updates) - the performance patch with that still had the problem.
Since I now have both Pd versions - hacked vanilla and extended - is there any test I can carry out to determine what the issue might be?
Ed  Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ed Kelly morph_2016@yahoo.co.uk Cc: "pd-list@iem.at" pd-list@iem.at Sent: Saturday, 5 January 2013, 0:08 Subject: Re: [PD] GUI overload
Have you tried using the Pd-extended PPA, there is a Lucid package there:
https://launchpad.net/~eighthave/+archive/pd-extended
sudo add-apt-repository ppa:eighthave/pd-extended
.hc
On Jan 4, 2013, at 6:15 PM, Ed Kelly wrote:
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later Ubuntu
versions to run on my new and old machines with no success, so I compiled the source code of Pd-extended 0.43 (2012-12-28 build). All was fine in linux_make/, then I tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd \
/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
test -z "" || (
install -p -m 644Â/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp && \
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2
? Ed Â
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 Subject: Re: [PD] GUI overload
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob] that make
them only
send the GUI updates when something actually has changed. This can
greatly
reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of Pd-extended and see
if you
still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent"
problem as
it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and I
find the following problem occurs. There comes a point where the GUI
objects
stop responding in a patch when it is reloaded. I am wondering if there
is a
specific limit to GUI objects that could be changed. I think Pd is
making some
kind of decision that "there's too much of this stuff -
I'm gonna
prioritize the audio and not worry about it" and I'd like to
know how
or if it is possible to control this process from within Pd, or by
setting flags
on the command line.
I'm also making less GUI intensive versions for performance
time, since
the really big GUI patches are often pattern-sequencers which I will
not want to
program when I am performing. Example patch enclosed to give you an
idea. The
really GUI-intensive objects are the trackers, especially quadtracker
(which I
think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4,
lots of
externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
One other occasion where I used to have the same thing happen to me which might shed some light on the situation.
Remember Brazil? I tried all evening to get my GUI-intensive patches working. Fortunately we did, in the end, get some music. It was all down to that pesky firewire interface, using Jack.
I had to run Pd in -rt mode, and I have found that running Pd in -rt often causes the GUI to seize up completely in my patches, in exactly the same way as it did for the latest one. I don't use Jack any more, nor do I ever run Pd in -rt mode. Without -rt I find I can do things like create a new [table] object and copy audio data from a recording of the [adc~] into the table, without any audio dropouts. Ed;
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Ed Kelly morph_2016@yahoo.co.uk Cc: Hans-Christoph Steiner hans@at.or.at; "pd-list@iem.at" pd-list@iem.at Sent: Saturday, 5 January 2013, 4:18 Subject: Re: [PD] GUI overload
So now a question for me is - should I change || to + in the 0.44 release? My first impulse is to hold off since I can't be sure it won't affect scheduling in some other unknown way - after al if it makes one thing happen faster it presumably makes something else happen slower.
I'm hoping to make 0.44 official this weekend :)
M
On Sat, Jan 05, 2013 at 01:07:44AM +0000, Ed Kelly wrote:
Oooh, aargh, exactly the same!
San Diego (Houston) we have a problem...Miller's sys_pollgui() fix is
the only one I found that works, and perhaps we don't know why it works, but it works for me. Bear in mind I have 32x64+256=2304 GUI objects to update when the pattern changes on my sequencer, but I'm not entirely convinced that is the whole problem. The version I sent you (with all those GUI updates) worked fine it turned out, but the version I made of the sequencer to try to counteract this (with no GUI updates) - the performance patch with that still had the problem.
Since I now have both Pd versions - hacked vanilla and extended - is there
any test I can carry out to determine what the issue might be?
Ed Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ed Kelly morph_2016@yahoo.co.uk Cc: "pd-list@iem.at" pd-list@iem.at Sent: Saturday, 5 January 2013, 0:08 Subject: Re: [PD] GUI overload
Have you tried using the Pd-extended PPA, there is a Lucid package
there:
https://launchpad.net/~eighthave/+archive/pd-extended
sudo add-apt-repository ppa:eighthave/pd-extended
.hc
On Jan 4, 2013, at 6:15 PM, Ed Kelly wrote:
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later
Ubuntu
versions to run on my new and old machines with no success, so I
compiled the
source code of Pd-extended 0.43 (2012-12-28 build). All was fine in
linux_make/,
then I tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd \
/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
test -z "" || (
install -p -m 644/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
&& \
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2
? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 Subject: Re: [PD] GUI overload
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob]
that make
them only
send the GUI updates when something actually has changed.
This can
greatly
reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of
Pd-extended and see
if you
still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a
"recurrent"
problem as
it's hard to say whether the rewrite of the GUI has
affected it...
I'm using a lot of abstractions with larger GOP or
non-GOP
GUIs, and I
find the following problem occurs. There comes a point where
the GUI
objects
stop responding in a patch when it is reloaded. I am
wondering if there
is a
specific limit to GUI objects that could be changed. I think
Pd is
making some
kind of decision that "there's too much of this
stuff -
I'm gonna
prioritize the audio and not worry about it" and I'd
like to
know how
or if it is possible to control this process from within Pd,
or by
setting flags
on the command line.
I'm also making less GUI intensive versions for
performance
time, since
the really big GUI patches are often pattern-sequencers which
I will
not want to
program when I am performing. Example patch enclosed to give
you an
idea. The
really GUI-intensive objects are the trackers, especially
quadtracker
(which I
think has pushed the GUI of Pd patches about as far as I can
go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4,
lots of
externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
What would be very useful for me for debugging is if your patch ran on plain Pd-extended, and included every object outside of Pd-extended it needs to run. When I open your Test.perf patch, I get quite a few errors amount missing objects.
.hc
On Jan 5, 2013, at 6:05 AM, Ed Kelly wrote:
One other occasion where I used to have the same thing happen to me which might shed some light on the situation.
Remember Brazil? I tried all evening to get my GUI-intensive patches working. Fortunately we did, in the end, get some music. It was all down to that pesky firewire interface, using Jack.
I had to run Pd in -rt mode, and I have found that running Pd in -rt often causes the GUI to seize up completely in my patches, in exactly the same way as it did for the latest one. I don't use Jack any more, nor do I ever run Pd in -rt mode. Without -rt I find I can do things like create a new [table] object and copy audio data from a recording of the [adc~] into the table, without any audio dropouts.
Ed;
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Ed Kelly morph_2016@yahoo.co.uk Cc: Hans-Christoph Steiner hans@at.or.at; "pd-list@iem.at" pd-list@iem.at Sent: Saturday, 5 January 2013, 4:18 Subject: Re: [PD] GUI overload
So now a question for me is - should I change || to + in the 0.44 release? My first impulse is to hold off since I can't be sure it won't affect scheduling in some other unknown way - after al if it makes one thing happen faster it presumably makes something else happen slower.
I'm hoping to make 0.44 official this weekend :)
M
On Sat, Jan 05, 2013 at 01:07:44AM +0000, Ed Kelly wrote:
Oooh, aargh, exactly the same!
San Diego (Houston) we have a problem...Miller's sys_pollgui() fix is
the only one I found that works, and perhaps we don't know why it works, but it works for me. Bear in mind I have 32x64+256=2304 GUI objects to update when the pattern changes on my sequencer, but I'm not entirely convinced that is the whole problem. The version I sent you (with all those GUI updates) worked fine it turned out, but the version I made of the sequencer to try to counteract this (with no GUI updates) - the performance patch with that still had the problem.
Since I now have both Pd versions - hacked vanilla and extended - is there
any test I can carry out to determine what the issue might be?
Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ed Kelly morph_2016@yahoo.co.uk Cc: "pd-list@iem.at" pd-list@iem.at Sent: Saturday, 5 January 2013, 0:08 Subject: Re: [PD] GUI overload
Have you tried using the Pd-extended PPA, there is a Lucid package
there:
https://launchpad.net/~eighthave/+archive/pd-extended
sudo add-apt-repository ppa:eighthave/pd-extended
.hc
On Jan 4, 2013, at 6:15 PM, Ed Kelly wrote:
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later
Ubuntu
versions to run on my new and old machines with no success, so I
compiled the
source code of Pd-extended 0.43 (2012-12-28 build). All was fine in
linux_make/,
then I tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd \
/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
test -z "" || (
install -p -m 644/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
&& \
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2
? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 Subject: Re: [PD] GUI overload
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob]
that make
them only
send the GUI updates when something actually has changed.
This can
greatly
reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of
Pd-extended and see
if you
still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote: > Hi List, > > I'm not going to say whether this is a
"recurrent"
problem as
it's hard to say whether the rewrite of the GUI has
affected it...
> > I'm using a lot of abstractions with larger GOP or
non-GOP
GUIs, and I
find the following problem occurs. There comes a point where
the GUI
objects
stop responding in a patch when it is reloaded. I am
wondering if there
is a
specific limit to GUI objects that could be changed. I think
Pd is
making some
kind of decision that "there's too much of this
stuff -
I'm gonna
prioritize the audio and not worry about it" and I'd
like to
know how
or if it is possible to control this process from within Pd,
or by
setting flags
on the command line. > > I'm also making less GUI intensive versions for
performance
time, since
the really big GUI patches are often pattern-sequencers which
I will
not want to
program when I am performing. Example patch enclosed to give
you an
idea. The
really GUI-intensive objects are the trackers, especially
quadtracker
(which I
think has pushed the GUI of Pd patches about as far as I can
go now).
> > System: quad core i5 PC running Ubuntu (10.04 Lucid),
Pd-0.43-4,
lots of
externals compiled and loaded. > > Warm wishes, > Ed > > Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
> http://sharktracks.co.uk/ > > > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
As far as freezes-- with the -rt flag isn't Pd running at a higher priority than the x server?
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ed Kelly morph_2016@yahoo.co.uk Cc: "pd-list@iem.at" pd-list@iem.at; Miller Puckette msp@ucsd.edu Sent: Saturday, January 5, 2013 11:36 PM Subject: Re: [PD] GUI overload
What would be very useful for me for debugging is if your patch ran on plain Pd-extended, and included every object outside of Pd-extended it needs to run. When I open your Test.perf patch, I get quite a few errors amount missing objects.
.hc
On Jan 5, 2013, at 6:05 AM, Ed Kelly wrote:
One other occasion where I used to have the same thing happen to me which
might shed some light on the situation.
Remember Brazil? I tried all evening to get my GUI-intensive patches
working. Fortunately we did, in the end, get some music. It was all down to that pesky firewire interface, using Jack.
I had to run Pd in -rt mode, and I have found that running Pd in -rt often
causes the GUI to seize up completely in my patches, in exactly the same way as it did for the latest one. I don't use Jack any more, nor do I ever run Pd in -rt mode. Without -rt I find I can do things like create a new [table] object and copy audio data from a recording of the [adc~] into the table, without any audio dropouts.
Ed;
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Ed Kelly morph_2016@yahoo.co.uk Cc: Hans-Christoph Steiner hans@at.or.at;
"pd-list@iem.at" pd-list@iem.at
Sent: Saturday, 5 January 2013, 4:18 Subject: Re: [PD] GUI overload
So now a question for me is - should I change || to + in the 0.44 release? My first impulse is to hold off since I can't be sure it won't affect scheduling in some other unknown way - after al if it
makes
one thing happen faster it presumably makes something else happen slower.
I'm hoping to make 0.44 official this weekend :)
M
On Sat, Jan 05, 2013 at 01:07:44AM +0000, Ed Kelly wrote:
Oooh, aargh, exactly the same!
San Diego (Houston) we have a problem...Miller's sys_pollgui()
fix is
the only one I found that works, and perhaps we don't know why it
works, but
it works for me. Bear in mind I have 32x64+256=2304 GUI objects to
update when
the pattern changes on my sequencer, but I'm not entirely convinced
that is
the whole problem. The version I sent you (with all those GUI updates)
worked
fine it turned out, but the version I made of the sequencer to try to
counteract
this (with no GUI updates) - the performance patch with that still had
the
problem.
Since I now have both Pd versions - hacked vanilla and extended -
is there
any test I can carry out to determine what the issue might be?
Ed Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ed Kelly morph_2016@yahoo.co.uk Cc: "pd-list@iem.at" pd-list@iem.at Sent: Saturday, 5 January 2013, 0:08 Subject: Re: [PD] GUI overload
Have you tried using the Pd-extended PPA, there is a Lucid
package
there:
https://launchpad.net/~eighthave/+archive/pd-extended
sudo add-apt-repository ppa:eighthave/pd-extended
.hc
On Jan 4, 2013, at 6:15 PM, Ed Kelly wrote:
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get
later
Ubuntu
versions to run on my new and old machines with no success, so
I
compiled the
source code of Pd-extended 0.43 (2012-12-28 build). All was
fine in
linux_make/,
then I tried "sudo make install" from packages
directory.
install -p -m 644 jmmmp-meta.pd \
/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
test -z "" || (
install -p -m 644/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
&& \
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2
? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
----- Original Message ----- > From: Hans-Christoph Steiner hans@at.or.at > To: pd-list@iem.at > Cc: > Sent: Friday, 28 December 2012, 5:22 > Subject: Re: [PD] GUI overload > > > Hey Ed, > > I just committed a couple more fixes for [tgl] and
[mknob]
that make
them only
> send the GUI updates when something actually has
changed.
This can
greatly
> reduce the amount of traffic to the GUI. > > Can you try your patch with the 2012-12-28 build of
Pd-extended and see
if you
> still get freezes? > http://autobuild.puredata.info/auto-build/2012-12-28/ > > .hc > > On 12/16/2012 08:47 AM, Ed Kelly wrote: >> Hi List, >> >> I'm not going to say whether this is a
"recurrent"
problem as
> it's hard to say whether the rewrite of the GUI
has
affected it...
>> >> I'm using a lot of abstractions with larger
GOP or
non-GOP
GUIs, and I
> find the following problem occurs. There comes a
point where
the GUI
objects
> stop responding in a patch when it is reloaded. I am
wondering if there
is a
> specific limit to GUI objects that could be changed.
I think
Pd is
making some
> kind of decision that "there's too much of
this
stuff -
I'm gonna
> prioritize the audio and not worry about it" and
I'd
like to
know how
> or if it is possible to control this process from
within Pd,
or by
setting flags
> on the command line. >> >> I'm also making less GUI intensive versions
for
performance
time, since
> the really big GUI patches are often
pattern-sequencers which
I will
not want to
> program when I am performing. Example patch enclosed
to give
you an
idea. The
> really GUI-intensive objects are the trackers,
especially
quadtracker
(which I
> think has pushed the GUI of Pd patches about as far
as I can
go now).
>> >> System: quad core i5 PC running Ubuntu (10.04
Lucid),
Pd-0.43-4,
lots of
> externals compiled and loaded. >> >> Warm wishes, >> Ed >> >> Gemnotes-0.2: Live music notation for Pure Data,
now with
dynamics!
>> http://sharktracks.co.uk/ >> >> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >> > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
As far as freezes-- with the -rt flag isn't Pd running at a higher
priority than the x server?
Oh yes, you're right about that. Consider that irrelevant to the original GUI overload issue.
Ed
-Jonathan
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ed Kelly morph_2016@yahoo.co.uk Cc: "pd-list@iem.at" pd-list@iem.at; Miller Puckette
Sent: Saturday, January 5, 2013 11:36 PM Subject: Re: [PD] GUI overload
What would be very useful for me for debugging is if your patch ran on
plain
Pd-extended, and included every object outside of Pd-extended it needs to
run.
When I open your Test.perf patch, I get quite a few errors amount missing objects.
.hc
On Jan 5, 2013, at 6:05 AM, Ed Kelly wrote:
One other occasion where I used to have the same thing happen to me
which
might shed some light on the situation.
Remember Brazil? I tried all evening to get my GUI-intensive patches
working. Fortunately we did, in the end, get some music. It was all down to
that
pesky firewire interface, using Jack.
I had to run Pd in -rt mode, and I have found that running Pd in -rt
often
causes the GUI to seize up completely in my patches, in exactly the same
way as
it did for the latest one. I don't use Jack any more, nor do I ever run
Pd
in -rt mode. Without -rt I find I can do things like create a new [table]
object
and copy audio data from a recording of the [adc~] into the table, without
any
audio dropouts.
Ed;
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Miller Puckette msp@ucsd.edu To: Ed Kelly morph_2016@yahoo.co.uk Cc: Hans-Christoph Steiner hans@at.or.at;
"pd-list@iem.at" pd-list@iem.at
Sent: Saturday, 5 January 2013, 4:18 Subject: Re: [PD] GUI overload
So now a question for me is - should I change || to + in the 0.44 release? My first impulse is to hold off since I can't be
sure it
won't affect scheduling in some other unknown way - after al
if it
makes
one thing happen faster it presumably makes something else happen slower.
I'm hoping to make 0.44 official this weekend :)
M
On Sat, Jan 05, 2013 at 01:07:44AM +0000, Ed Kelly wrote:
Oooh, aargh, exactly the same!
San Diego (Houston) we have a problem...Miller's
sys_pollgui()
fix is
the only one I found that works, and perhaps we don't know why
it
works, but
it works for me. Bear in mind I have 32x64+256=2304 GUI objects to
update when
the pattern changes on my sequencer, but I'm not entirely
convinced
that is
the whole problem. The version I sent you (with all those GUI
updates)
worked
fine it turned out, but the version I made of the sequencer to try
to
counteract
this (with no GUI updates) - the performance patch with that still
had
the
problem.
Since I now have both Pd versions - hacked vanilla and
extended -
is there
any test I can carry out to determine what the issue might be?
Ed Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Ed Kelly morph_2016@yahoo.co.uk Cc: "pd-list@iem.at" pd-list@iem.at Sent: Saturday, 5 January 2013, 0:08 Subject: Re: [PD] GUI overload
Have you tried using the Pd-extended PPA, there is a Lucid
package
there:
https://launchpad.net/~eighthave/+archive/pd-extended
sudo add-apt-repository ppa:eighthave/pd-extended
.hc
On Jan 4, 2013, at 6:15 PM, Ed Kelly wrote:
> Hey Hans... > > I'm on Lucid (10.04LTS Ubuntu). I've tried
to get
later
Ubuntu
versions to run on my new and old machines with no
success, so
I
compiled the
source code of Pd-extended 0.43 (2012-12-28 build). All
was
fine in
linux_make/,
then I tried "sudo make install" from packages
directory.
> > install -p -m 644 jmmmp-meta.pd
>/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
> test -z "" || (
> install -p -m 644/home/edward/software/pd/extended/0.43/pd-extended/packages/build/lib/pd-extended/extra/jmmmp
&&
> ) > /bin/sh: Syntax error: ")" unexpected > make[2]: *** [libdir_install] Error 2 > > ? > Ed > > > Gemnotes-0.2: Live music notation for Pure Data, nowwith
dynamics!
> http://sharktracks.co.uk/ > > > > ----- Original Message ----- >> From: Hans-Christoph Steiner
>> To: pd-list@iem.at >> Cc: >> Sent: Friday, 28 December 2012, 5:22 >> Subject: Re: [PD] GUI overload >> >> >> Hey Ed, >> >> I just committed a couple more fixes for [tgl]
and
[mknob]
that make
them only >> send the GUI updates when something actually has
changed.
This can
greatly >> reduce the amount of traffic to the GUI. >> >> Can you try your patch with the 2012-12-28 build
of
Pd-extended and see
if you >> still get freezes? >>
http://autobuild.puredata.info/auto-build/2012-12-28/
>> >> .hc >> >> On 12/16/2012 08:47 AM, Ed Kelly wrote: >>> Hi List, >>> >>> I'm not going to say whether this is a
"recurrent"
problem as >> it's hard to say whether the rewrite of the
GUI
has
affected it...
>>> >>> I'm using a lot of abstractions with
larger
GOP or
non-GOP
GUIs, and I >> find the following problem occurs. There comes a
point where
the GUI
objects >> stop responding in a patch when it is reloaded.
I am
wondering if there
is a >> specific limit to GUI objects that could be
changed.
I think
Pd is
making some >> kind of decision that "there's too much
of
this
stuff -
I'm gonna >> prioritize the audio and not worry about
it" and
I'd
like to
know how >> or if it is possible to control this process
from
within Pd,
or by
setting flags >> on the command line. >>> >>> I'm also making less GUI intensive
versions
for
performance
time, since >> the really big GUI patches are often
pattern-sequencers which
I will
not want to >> program when I am performing. Example patch
enclosed
to give
you an
idea. The >> really GUI-intensive objects are the trackers,
especially
quadtracker
(which I >> think has pushed the GUI of Pd patches about as
far
as I can
go now).
>>> >>> System: quad core i5 PC running Ubuntu
(10.04
Lucid),
Pd-0.43-4,
lots of >> externals compiled and loaded. >>> >>> Warm wishes, >>> Ed >>> >>> Gemnotes-0.2: Live music notation for Pure
Data,
now with
dynamics!
>>> http://sharktracks.co.uk/ >>> >>> >>> >>>
>>> Pd-list@iem.at mailing list >>> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >>> >> >> _______________________________________________ >> Pd-list@iem.at mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >>
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
While you're at it, it would be great if you could also try pd-l2ork and report any gui overload issues. There are debs available on the site (http://l2ork.music.vt.edu), although the most up-to-date ones are found in the http://l2ork.music.vt.edu/data/pd/ folder. You can also install from git using automated install script.
Best wishes,
Ico
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Ed Kelly Sent: Friday, January 04, 2013 6:16 PM To: Hans-Christoph Steiner; pd-list@iem.at Subject: Re: [PD] GUI overload
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later Ubuntu versions to
run
on my new and old machines with no success, so I compiled the source code of Pd-extended 0.43 (2012-12-28 build). All was fine in linux_make/, then
I
tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd
/home/edward/software/pd/extended/0.43/pd- extended/packages/build/lib/pd-extended/extra/jmmmp test -z "" || (
install -p -m 644 /home/edward/software/pd/extended/0.43/pd- extended/packages/build/lib/pd-extended/extra/jmmmp &&
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 Subject: Re: [PD] GUI overload
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob] that make them only send the GUI updates when something actually has changed. This can greatly reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of Pd-extended and see if you still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent" problem as
it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP GUIs, and I
find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too much of this stuff - I'm gonna prioritize the audio and not worry about it" and I'd like to know how or if it is possible to control this process from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance time, since
the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches
about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of
externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
While you're at it, it would be great if you could also try pd-l2ork and
report any gui overload issues. There are debs available on the site (http://l2ork.music.vt.edu), although the most up-to-date ones are found in the http://l2ork.music.vt.edu/data/pd/ folder. You can also install from git using automated install script.
Is it independent of the normal Pd install? Its just I have some gigs coming up, and I don't want to fry the (stable) system I have. Especially with teaching starting again next week (less time vs eating)
I have an old Dell laptop I can test on if not, once I get the Broadcom WiFi working in Ubuntu.
Ed
Best wishes,
Ico
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Ed Kelly Sent: Friday, January 04, 2013 6:16 PM To: Hans-Christoph Steiner; pd-list@iem.at Subject: Re: [PD] GUI overload
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later Ubuntu
versions to run
on my new and old machines with no success, so I compiled the source code of Pd-extended 0.43 (2012-12-28 build). All was fine in linux_make/, then
I
tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd
/home/edward/software/pd/extended/0.43/pd- extended/packages/build/lib/pd-extended/extra/jmmmp test -z "" || (
install -p -m 644 /home/edward/software/pd/extended/0.43/pd- extended/packages/build/lib/pd-extended/extra/jmmmp &&
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 Subject: Re: [PD] GUI overload
Hey Ed,
I just committed a couple more fixes for [tgl] and [mknob] that make them only send the GUI updates when something actually has changed. This can greatly reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of Pd-extended and see if you still get freezes? http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent"
problem as
it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and
I
find the following problem occurs. There comes a point where the GUI objects stop responding in a patch when it is reloaded. I am wondering if there is a specific limit to GUI objects that could be changed. I think Pd is making some kind of decision that "there's too
much of
this stuff - I'm gonna prioritize the audio and not worry about
it"
and I'd like to know how or if it is possible to control this
process
from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance
time,
since
the really big GUI patches are often pattern-sequencers which I will not want to program when I am performing. Example patch enclosed to give you an idea. The really GUI-intensive objects are the trackers, especially quadtracker (which I think has pushed the GUI of Pd patches
about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of
externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
If you install it using binary tarball (or build it using ./tar_em_up -u), it will install into /usr/local/lib/ folder so it shouldn't mess with the regular pd/pd-extended. The deb OTOH cannot (yet) coexist with pd-extended, mainly due to shared names of some of the binaries (e.g. pd-gui)...
HTH
-----Original Message----- From: Ed Kelly [mailto:morph_2016@yahoo.co.uk] Sent: Friday, January 04, 2013 8:18 PM To: Ivica Ico Bukvic; 'Hans-Christoph Steiner'; pd-list@iem.at Subject: Re: [PD] GUI overload
While you're at it, it would be great if you could also try pd-l2ork and
report any gui overload issues. There are debs available on the site (http://l2ork.music.vt.edu), although the most up-to-date ones are found in the http://l2ork.music.vt.edu/data/pd/ folder. You can also install from git using automated install script.
Is it independent of the normal Pd install? Its just I have some gigs
coming
up, and I don't want to fry the (stable) system I have. Especially with
teaching
starting again next week (less time vs eating)
I have an old Dell laptop I can test on if not, once I get the Broadcom
WiFi
working in Ubuntu.
Ed
Best wishes,
Ico
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of Ed Kelly Sent: Friday, January 04, 2013 6:16 PM To: Hans-Christoph Steiner; pd-list@iem.at Subject: Re: [PD] GUI overload
Hey Hans...
I'm on Lucid (10.04LTS Ubuntu). I've tried to get later Ubuntu
versions to run
on my new and old machines with no success, so I compiled the source code of Pd-extended 0.43 (2012-12-28 build). All was fine in linux_make/, then
I
tried "sudo make install" from packages directory.
install -p -m 644 jmmmp-meta.pd
/home/edward/software/pd/extended/0.43/pd- extended/packages/build/lib/pd-extended/extra/jmmmp test -z "" || (
install -p -m 644 /home/edward/software/pd/extended/0.43/pd- extended/packages/build/lib/pd-extended/extra/jmmmp &&
) /bin/sh: Syntax error: ")" unexpected make[2]: *** [libdir_install] Error 2? Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at > To: pd-list@iem.at Cc: Sent: Friday, 28 December 2012, 5:22 > Subject: Re: [PD] GUI
overload > > > Hey Ed, > > I just committed a couple more fixes for [tgl] and [mknob] that make > them only send the GUI updates when something actually has changed.
This can greatly reduce the amount of traffic to the GUI.
Can you try your patch with the 2012-12-28 build of Pd-extended
and > see if you still get freezes?
http://autobuild.puredata.info/auto-build/2012-12-28/
.hc
On 12/16/2012 08:47 AM, Ed Kelly wrote:
Hi List,
I'm not going to say whether this is a "recurrent"
problem as
it's hard to say whether the rewrite of the GUI has affected it...
I'm using a lot of abstractions with larger GOP or non-GOP
GUIs, and
I
find the following problem occurs. There comes a point where the
GUI > objects stop responding in a patch when it is reloaded. I am wondering > if there is a specific limit to GUI objects that could be changed. I > think Pd is making some kind of decision that "there's too
much of
this stuff - I'm gonna prioritize the audio and not worry about
it"
and I'd like to know how or if it is possible to control this
process
from within Pd, or by setting flags on the command line.
I'm also making less GUI intensive versions for performance
time,
since
the really big GUI patches are often pattern-sequencers which I
will > not want to program when I am performing. Example patch enclosed to > give you an idea. The really GUI-intensive objects are the trackers, > especially quadtracker (which I think has pushed the GUI of Pd patches about as far as I can go now).
System: quad core i5 PC running Ubuntu (10.04 Lucid), Pd-0.43-4, lots of > externals compiled and loaded.
Warm wishes, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with
dynamics!
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> >
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> >
http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Ed Kelly -
Hans-Christoph Steiner -
Ivica Bukvic -
Ivica Ico Bukvic
-
Jonathan Wilkes -
Miller Puckette