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:[email protected]] > Sent: Thursday, December 20, 2012 11:46 PM > To: Ivica Bukvic > Cc: [email protected] > 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" <[email protected]> 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=5573 > 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/ > > > > >>>>> > > > > >>>>> > > > > >>>>>> _______________________________________________ > > > > >>>>>> [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 > > > > > > _______________________________________________ > > [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
