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: [email protected] [mailto:[email protected]] On Behalf Of > Hans-Christoph Steiner > Sent: Thursday, February 14, 2013 10:07 PM > To: [email protected] > 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:[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 > > > > _______________________________________________ > [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
