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=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
