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