If you are not installing it onto system, copy TCL files into the pd/bin dir. Remember, this is a fork of 0.42. On Oct 24, 2012 9:07 PM, "Hans-Christoph Steiner" <h...@at.or.at> wrote:
> > I just tried the latest pd-l2ork from git, and it doesn't seem to start > correctly. I did: > > cd pd/src > aclocal > autoconf > ./configure > make > ../bin/pd-l2ork > > I also tried: > > cd ../bin > ./pd-l2ork > > All I got was a great square window with no menu. I'm on Linux Mint 13 > Maya > amd64, which is basically Ubuntu/Precise. > > .hc > > > On 10/24/2012 08:47 PM, Ivica Bukvic wrote: > > 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