It is only the draw command, not the communication... BTW do either of you know why one would be getting pdtk_post { stack overflow } messages? Doors that mean the cpu is unable to handle all gui requests? On Oct 24, 2012 8:32 PM, "Hans-Christoph Steiner" <h...@at.or.at> wrote:
> > Thanks for that info. Sounds like a good idea in general. I personally > can't > think of any reason why the DSP would need to be on during the quitting. > But > for the 'redraw' part, that depends. If it is literally only redrawing > that > is suspended, that would be fine. But if its all Pd<-->GUI communications, > that will probably cause problems. > > .hc > > On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote: > > Hans and Iohannes, > > > > The following is FYI. > > > > Several months ago I integrated the close all patches before quitting > patch > > in pd-l2ork and since then I've been experiencing extremely sporadic > crashes > > on close that would hang pd-l2ork. Now, I am not sure this is because of > > architectural differences between regular pd and pd-l2ork but I doubt it > > since most of the said components are very similar if not identical. > > > > The bottom line is this only occurs on very low-powered machines (e.g. > > netbook) and relatively large patches and even then it does so very > > sporadically. Consequently, I implemented an improvement to the closing > > mechanism that consists of 2 additional steps and apparently alleviates > said > > problems entirely: > > > > 1) disable further redraws (this prevents calling functions that may be > > referencing null pointers)--I have a special global var for this which is > > also being used to optimize redrawing (many actions in pd-l2ork are > several > > times faster than regular pd as a result of this implementation--just > look > > for do_not_redraw call in the source if curious) > > > > 2) suspend dsp before going through the patches (all sub-patches try to > > suspend it and resume it but for some reason, due to asynchronous nature > of > > communication between tcl and c funny things occasionally happen on > > low-powered machines, so this way we ensure it is entirely off throughout > > the whole destruction process) > > > > Hope this helps! > > > > Ivica Ico Bukvic, D.M.A. > > Composition, Music Technology > > Director, DISIS Interactive Sound & Intermedia Studio > > Director, L2Ork Linux Laptop Orchestra > > Head, ICAT IMPACT Studio > > Virginia Tech > > Dept. of Music - 0240 > > Blacksburg, VA 24061 > > (540) 231-6139 > > (540) 231-5034 (fax) > > i...@vt.edu > > http://www.music.vt.edu/faculty/bukvic/ > > > > > > >
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list