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=55736&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/ >>>>> >>>>> >>>>>> _______________________________________________ >>>>>> [email protected] mailing list >>>>>> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >>>>> >>>>> >>>>> _______________________________________________ >>>>> [email protected] mailing list >>>>> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >>>>> >>>> >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> http://lists.puredata.info/listinfo/pd-list >> _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
