Without seeing the patch this may be tricky to diagnose. If I had to guess, I would say you are redundantly updating something too quickly.
FWIW, in pd-l2ork k12 mode every object is a gop abstraction with many having live gui components. Even with dozens of such abstractions (I've seen as many as 50ish) and high rate of metros on a measly netbook, there were no problems...
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