Do you have tkpng installed as per instructions on pd-l2ork's webpage?
Hmm, something different, but still not running:
hans@palatschinken bin $ cp ../src/pd.tk .
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
tcl: /media/share/code/pd-l2ork/pd/bin/pd.tk: can't open script
^CPd: signal 2
hans@palatschinken bin $ ls -l /media/share/code/pd-l2ork/pd/bin/pd.tk
-rwxr-xr-x 1 hans hans 289074 Oct 24 23:55 /media/share/code/pd-l2ork/pd/bin/pd.tk
On 10/24/2012 10:56 PM, Ivica Bukvic wrote:
> 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:
>>>>>>>
>>>>>>> 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)
>>>>>>> ico@vt.edu
>>>>>>> http://www.music.vt.edu/faculty/bukvic/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>