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/
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/
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/
Stack overflow usually comes from recursiveness in patches until Pd's stack overflows, or at least that's my experience of that error.
The pdtk_post logic has changed a lot in 0.43 with drastic improvements. You can now post 1000 lines/sec and still patch in Pd.
In related work, I've been playing around with making array redrawing respect the Tk event loop more. Basically, each draw command you send gets queued until the event loop executes it. But for something like an array, there is no reason to draw multiple times in a single loop, so when a new draw command gets posted, it cancels the previous one if it hasn't run already. That is the key to what made pdtk_post so much faster as well. Another part of that is using "after idle" so that Tk doesn't drop everything to try to run that command, but instead queues it to happen in a big chunk.
You can see the first stab at this work for arrays in the attached patches. The first patch is only there because it needs to be applied for the 2nd patch to apply cleanly. They apply to pure-data.git master.
.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/
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/
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/
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/
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/
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/ > > >
Do you have tkpng installed as per instructions on pd-l2ork's webpage? On Oct 24, 2012 11:57 PM, "Hans-Christoph Steiner" hans@at.or.at wrote:
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/ >> >> >> >
yup:
hans@palatschinken bin $ dpkg -l tkpng Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description +++-================-================-================================================ ii tkpng 0.9-1ubuntu1 PNG photo image support to Tcl/Tk
Does it not work with Tcl/Tk 8.5?
hans@palatschinken bin $ tclsh % info patchlevel 8.5.11
.hc
On 10/25/2012 12:11 AM, Ivica Bukvic wrote:
Do you have tkpng installed as per instructions on pd-l2ork's webpage? On Oct 24, 2012 11:57 PM, "Hans-Christoph Steiner" hans@at.or.at wrote:
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/ >>> >>> >>> >> >
Just tried it here, works fine. There are some older versions of tcl/tk files in the bin directory I forgot to clean out so make sure to explicitly copy all tcl/tk files, like so:
cd pd/bin cp ../src/pd.tk . cp ../src/*tcl . ./pd-l2ork
That said, running core pd-l2ork without all the customized externals will only give you a limited picture. E.g. pd-l2ork uses a custom version of cwiid that supports wiimote passthrough mode, but that requires installing the custom version of cwiid. If you are using the full installer, this will be done for you...
Best wishes,
Ico
-----Original Message----- From: Hans-Christoph Steiner [mailto:hans@at.or.at] Sent: Thursday, October 25, 2012 12:18 AM To: Ivica Bukvic Cc: pd-list; IOhannes m zmoelnig Subject: Re: close all patches on quit sourceforge patch
yup:
hans@palatschinken bin $ dpkg -l tkpng Desired=Unknown/Install/Remove/Purge/Hold | |Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig |-pend / Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description
+++-================-================-
+++============== ii tkpng 0.9-1ubuntu1 PNG photo image support to Tcl/Tk
Does it not work with Tcl/Tk 8.5?
hans@palatschinken bin $ tclsh % info patchlevel 8.5.11
.hc
On 10/25/2012 12:11 AM, Ivica Bukvic wrote:
Do you have tkpng installed as per instructions on pd-l2ork's webpage? On Oct 24, 2012 11:57 PM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
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/ >>>> >>>> >>>> >>> >> >
Ah, that was it. I did "cp ../tcl/*.tcl" and now it works. Maybe you could just delete the stuff in tcl/ if its not in use?
I'll try the full distro too, I just want a way to quickly check stuff in your git.
.hc
On 10/25/2012 09:07 AM, Ivica Ico Bukvic wrote:
Just tried it here, works fine. There are some older versions of tcl/tk files in the bin directory I forgot to clean out so make sure to explicitly copy all tcl/tk files, like so:
cd pd/bin cp ../src/pd.tk . cp ../src/*tcl . ./pd-l2ork
That said, running core pd-l2ork without all the customized externals will only give you a limited picture. E.g. pd-l2ork uses a custom version of cwiid that supports wiimote passthrough mode, but that requires installing the custom version of cwiid. If you are using the full installer, this will be done for you...
Best wishes,
Ico
-----Original Message----- From: Hans-Christoph Steiner [mailto:hans@at.or.at] Sent: Thursday, October 25, 2012 12:18 AM To: Ivica Bukvic Cc: pd-list; IOhannes m zmoelnig Subject: Re: close all patches on quit sourceforge patch
yup:
hans@palatschinken bin $ dpkg -l tkpng Desired=Unknown/Install/Remove/Purge/Hold | |Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig |-pend / Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Description
+++-================-================-
+++============== ii tkpng 0.9-1ubuntu1 PNG photo image support to Tcl/Tk
Does it not work with Tcl/Tk 8.5?
hans@palatschinken bin $ tclsh % info patchlevel 8.5.11
.hc
On 10/25/2012 12:11 AM, Ivica Bukvic wrote:
Do you have tkpng installed as per instructions on pd-l2ork's webpage? On Oct 24, 2012 11:57 PM, "Hans-Christoph Steiner" hans@at.or.at
wrote:
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/ >>>>> >>>>> >>>>> >>>> >>> >> >
That said, running core pd-l2ork without all the customized externals will
only
give you a limited picture. E.g. pd-l2ork uses a custom version of cwiid
that
supports wiimote passthrough mode, but that requires installing the custom version of cwiid. If you are using the full installer, this will be done
for you...
To add to this, -k12 flag (or K12 mode) will not work unless you have full thing installed as it relies upon additional files found in the K12 module...
On 10/25/2012 09:09 AM, Ivica Ico Bukvic wrote:
That said, running core pd-l2ork without all the customized externals will
only
give you a limited picture. E.g. pd-l2ork uses a custom version of cwiid
that
supports wiimote passthrough mode, but that requires installing the custom version of cwiid. If you are using the full installer, this will be done
for you...
To add to this, -k12 flag (or K12 mode) will not work unless you have full thing installed as it relies upon additional files found in the K12 module...
The -k12 mode is nice :)
FYI, what started me on the kick is tracking down GUI slowness bugs. There are two that I"m currently working on that affect Pd-vanilla, Pd-extended, and pd-l2ork >= 0.42:
- [bng] stops flashing when data comes in faster than every 50ms
- arrays stop showing updates when data comes in faster than every 100ms
I've almost got a complete fix for the [bng] problem, it now stops flashing <10ms, I think I can it working always. The source of the array problem still eludes me, here's that thread: http://lists.puredata.info/pipermail/pd-dev/2012-10/018679.html
I attached test patches for both of these problems.
.hc
I'll try to check this out. I think the problem is the socket-based communication which is really a pain. When a cpu is on powersave mode it appears the sockets are such a low priority at times some messages arrive up to a half-second later... And this is on a lowlatency kernel too...
Once I solidify the pd-l2ork code and release a stable version (and we appear to be darn close to it now), one of the things on my todo list is to do away with socket-based communication in favor of queuing calls via a separate thread. Sure, one will lose gui-less operation but with libpd around, I don't see a point in trying to maintain gui-less implementation (which from what I saw on the list appears to have a fair share of its own problems, please correct me if I am wrong here).
P.S. Don't forget to check out the preset_hub and preset_node (k12 mode uses it so that you can store all states even among multiple instances of same abstraction, which is virtually impossible otherwise). Currently the documentation is not yet integrated (thanks to Jonathan for his work on this) but there are example patches in the complete source inside pd/src folder...
Best wishes,
Ico
-----Original Message----- From: Hans-Christoph Steiner [mailto:hans@at.or.at] Sent: Thursday, October 25, 2012 12:48 PM To: Ivica Ico Bukvic Cc: 'pd-list'; 'IOhannes m zmoelnig' Subject: Re: close all patches on quit sourceforge patch
On 10/25/2012 09:09 AM, Ivica Ico Bukvic wrote:
That said, running core pd-l2ork without all the customized externals will
only
give you a limited picture. E.g. pd-l2ork uses a custom version of cwiid
that
supports wiimote passthrough mode, but that requires installing the custom version of cwiid. If you are using the full installer, this will be done
for you...
To add to this, -k12 flag (or K12 mode) will not work unless you have full thing installed as it relies upon additional files found in the K12 module...
The -k12 mode is nice :)
FYI, what started me on the kick is tracking down GUI slowness bugs.
There
are two that I"m currently working on that affect Pd-vanilla, Pd-extended, and pd-l2ork >= 0.42:
- [bng] stops flashing when data comes in faster than every 50ms
- arrays stop showing updates when data comes in faster than every 100ms
I've almost got a complete fix for the [bng] problem, it now stops
flashing
<10ms, I think I can it working always. The source of the array problem
still
eludes me, here's that thread: http://lists.puredata.info/pipermail/pd-dev/2012-10/018679.html
I attached test patches for both of these problems.
.hc
I always get (Tcl) UNHANDLED ERROR: bad window path name ".x94d6a18.c" while executing "winfo toplevel $tkcanvas" (procedure "pdtk_canvas_getscroll" line 2) invoked from within "pdtk_canvas_getscroll .x94d6a18.c" ("uplevel" body line 349) invoked from within "uplevel #0 $cmd_from_pd
when I open a voice patch from it's parent patch and edit then save from there instead of opening the voice abstraction from file open instead
using pd vanilla from ubuntu 12.04 "not sure of version "about" is broken
not sure if that has anything to do with what you guys are talking about i'm not familiar with anything tcl tk
On 11/01/2012 05:55 PM, Billy Stiltner wrote:
not sure if that has anything to do with what you guys are talking about i'm not familiar with anything tcl tk
no (unless i misunderstood what we are talking about)
fgmadsr IOhannes
Can you provide an example patch that does this every time? If so, please file a bug report (Help -> Report Bug).
.hc
On Nov 1, 2012, at 12:55 PM, Billy Stiltner wrote:
I always get (Tcl) UNHANDLED ERROR: bad window path name ".x94d6a18.c" while executing "winfo toplevel $tkcanvas" (procedure "pdtk_canvas_getscroll" line 2) invoked from within "pdtk_canvas_getscroll .x94d6a18.c" ("uplevel" body line 349) invoked from within "uplevel #0 $cmd_from_pd
when I open a voice patch from it's parent patch and edit then save from there instead of opening the voice abstraction from file open instead
using pd vanilla from ubuntu 12.04 "not sure of version "about" is broken
not sure if that has anything to do with what you guys are talking about i'm not familiar with anything tcl tk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-25 06:18, Hans-Christoph Steiner wrote:
yup:
hans@palatschinken bin $ dpkg -l tkpng Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description +++-================-================-================================================
ii tkpng 0.9-1ubuntu1 PNG photo image support to Tcl/Tk
Does it not work with Tcl/Tk 8.5?
hans@palatschinken bin $ tclsh % info patchlevel 8.5.11
works here:
zmoelnig@ferrari:~$ tclsh % info patchlevel 8.5.11 zmoelnig@ferrari:~$ dpkg -l tkpng ii tkpng 0.9-1 i386 PNG photo image support to Tcl/Tk
originally i had the same problem: $ ./pd-l2ork tcl: /tmp/pd-l2ork/bin/pd.tk: can't open script pd: exiting
but indeed i was missing tkpng first. i discovered this by directly running (after making pd.tk executable) $ ./pd.tk which initially threw an error "Error in startup script: can't find package tkpng".
so the "can't open script" error is a bit misleading (or generic).
attached is a small patch that prints the full error message of the Tcl-Interpreter.
fgmasdr IOhannes
Many thanks for sharing this, IOhannes! I've embellished your patch a bit and added it to pd-l2ork.
Best wishes,
Ico
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of IOhannes m zmoelnig Sent: Thursday, October 25, 2012 10:31 AM To: pd-list@iem.at Subject: Re: [PD] close all patches on quit sourceforge patch
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2012-10-25 06:18, Hans-Christoph Steiner wrote:
yup:
hans@palatschinken bin $ dpkg -l tkpng Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tri g-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description +++-================-================-
================================
+++================
ii tkpng 0.9-1ubuntu1 PNG photo image support to Tcl/Tk
Does it not work with Tcl/Tk 8.5?
hans@palatschinken bin $ tclsh % info patchlevel 8.5.11
works here:
zmoelnig@ferrari:~$ tclsh % info patchlevel 8.5.11 zmoelnig@ferrari:~$ dpkg -l tkpng ii tkpng 0.9-1 i386 PNG photo image support to Tcl/Tk
originally i had the same problem: $ ./pd-l2ork tcl: /tmp/pd-l2ork/bin/pd.tk: can't open script pd: exiting
but indeed i was missing tkpng first. i discovered this by directly
running
(after making pd.tk executable) $ ./pd.tk which initially threw an error
"Error
in startup script: can't find package tkpng".
so the "can't open script" error is a bit misleading (or generic).
attached is a small patch that prints the full error message of the Tcl- Interpreter.
fgmasdr IOhannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlCJTRYACgkQkX2Xpv6ydvRuzgCgwy8NkGHXHgWqK/kLgY2a7f Uh fVEAn3mn9prk3dEVd9ut/JGJN7tufk2h =SSeI -----END PGP SIGNATURE-----
-
Billy Stiltner -
Hans-Christoph Steiner -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Ivica Bukvic -
Ivica Ico Bukvic