<p dir="ltr">It is only the draw command, not the communication...</p>
<p dir="ltr">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?</p>
<div class="gmail_quote">On Oct 24, 2012 8:32 PM, "Hans-Christoph Steiner" <<a href="mailto:hans@at.or.at">hans@at.or.at</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks for that info. Sounds like a good idea in general. I personally can't<br>
think of any reason why the DSP would need to be on during the quitting. But<br>
for the 'redraw' part, that depends. If it is literally only redrawing that<br>
is suspended, that would be fine. But if its all Pd<-->GUI communications,<br>
that will probably cause problems.<br>
<br>
.hc<br>
<br>
On 10/24/2012 06:02 PM, Ivica Ico Bukvic wrote:<br>
> Hans and Iohannes,<br>
><br>
> The following is FYI.<br>
><br>
> Several months ago I integrated the close all patches before quitting patch<br>
> in pd-l2ork and since then I've been experiencing extremely sporadic crashes<br>
> on close that would hang pd-l2ork. Now, I am not sure this is because of<br>
> architectural differences between regular pd and pd-l2ork but I doubt it<br>
> since most of the said components are very similar if not identical.<br>
><br>
> The bottom line is this only occurs on very low-powered machines (e.g.<br>
> netbook) and relatively large patches and even then it does so very<br>
> sporadically. Consequently, I implemented an improvement to the closing<br>
> mechanism that consists of 2 additional steps and apparently alleviates said<br>
> problems entirely:<br>
><br>
> 1) disable further redraws (this prevents calling functions that may be<br>
> referencing null pointers)--I have a special global var for this which is<br>
> also being used to optimize redrawing (many actions in pd-l2ork are several<br>
> times faster than regular pd as a result of this implementation--just look<br>
> for do_not_redraw call in the source if curious)<br>
><br>
> 2) suspend dsp before going through the patches (all sub-patches try to<br>
> suspend it and resume it but for some reason, due to asynchronous nature of<br>
> communication between tcl and c funny things occasionally happen on<br>
> low-powered machines, so this way we ensure it is entirely off throughout<br>
> the whole destruction process)<br>
><br>
> Hope this helps!<br>
><br>
> Ivica Ico Bukvic, D.M.A.<br>
> Composition, Music Technology<br>
> Director, DISIS Interactive Sound & Intermedia Studio<br>
> Director, L2Ork Linux Laptop Orchestra<br>
> Head, ICAT IMPACT Studio<br>
> Virginia Tech<br>
> Dept. of Music - 0240<br>
> Blacksburg, VA 24061<br>
> (540) 231-6139<br>
> (540) 231-5034 (fax)<br>
> <a href="mailto:ico@vt.edu">ico@vt.edu</a><br>
> <a href="http://www.music.vt.edu/faculty/bukvic/" target="_blank">http://www.music.vt.edu/faculty/bukvic/</a><br>
><br>
><br>
><br>
</blockquote></div>