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:msp@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" msp@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=55... 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 ->
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list