You forgot pd.tk... On Oct 24, 2012 10:52 PM, "Hans-Christoph Steiner" hans@at.or.at wrote:
I did: cd pd/ cp tcl/*.tcl bin/ cd bin ./pd-l2ork
and got the same result:
hans@palatschinken bin $ ./pd-l2ork -stderr -d 3 set pd_whichmidiapi 2 pdtk_pd_startup {Pd version 0.42-6extended-l2ork-20121007 } { {OSS 2} {ALSA 1} } { {default-MIDI 2} {ALSA-MIDI 1} } {DejaVu Sans Mono} normal set pd_whichmidiapi 2
.hc
On 10/24/2012 10:16 PM, Ivica Bukvic wrote:
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" hans@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" hans@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:
- 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)
- 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) ico@vt.edu http://www.music.vt.edu/faculty/bukvic/