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:m...@ucsd.edu] >> Sent: Thursday, December 20, 2012 11:46 PM >> To: Ivica Bukvic >> Cc: pd-list@iem.at >> 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" <m...@ucsd.edu> 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/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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
