You forgot pd.tk...
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/
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>