<p dir="ltr">If you are not installing it onto system, copy TCL files into the pd/bin dir. Remember, this is a fork of 0.42.</p>
<div class="gmail_quote">On Oct 24, 2012 9:07 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>
I just tried the latest pd-l2ork from git, and it doesn't seem to start<br>
correctly. I did:<br>
<br>
cd pd/src<br>
aclocal<br>
autoconf<br>
./configure<br>
make<br>
../bin/pd-l2ork<br>
<br>
I also tried:<br>
<br>
cd ../bin<br>
./pd-l2ork<br>
<br>
All I got was a great square window with no menu. I'm on Linux Mint 13 Maya<br>
amd64, which is basically Ubuntu/Precise.<br>
<br>
.hc<br>
<br>
<br>
On 10/24/2012 08:47 PM, Ivica Bukvic wrote:<br>
> It is only the draw command, not the communication...<br>
><br>
> BTW do either of you know why one would be getting pdtk_post { stack<br>
> overflow } messages? Doors that mean the cpu is unable to handle all gui<br>
> requests?<br>
> On Oct 24, 2012 8:32 PM, "Hans-Christoph Steiner" <<a href="mailto:hans@at.or.at">hans@at.or.at</a>> wrote:<br>
><br>
>><br>
>> Thanks for that info. Sounds like a good idea in general. I personally<br>
>> can't<br>
>> think of any reason why the DSP would need to be on during the quitting.<br>
>> But<br>
>> for the 'redraw' part, that depends. If it is literally only redrawing<br>
>> 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<br>
>> patch<br>
>>> in pd-l2ork and since then I've been experiencing extremely sporadic<br>
>> 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<br>
>> 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<br>
>> several<br>
>>> times faster than regular pd as a result of this implementation--just<br>
>> 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<br>
>> 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>
>><br>
><br>
</blockquote></div>