Why would you run it with nosleep? I am also not familiar with this option--what does it do?
András Murányi muranyia@gmail.com wrote:
Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of which have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem.
Alrite, my knowledge is just not enough to teach moonlib (which i have put into /extra) where the pd headers are. What shall i modify in its makefile?
CFLAGS = -DPD -I"../../src" -Wall -W -g
...and it works! I have lots of 'consistency check failed: glist_findrtext' when running, plus sometimes 'tcl/tk error: unknown encoding "yahoo"' on the terminal. It seems somewhat faster than the father, but that could also be that i've compiled it for my CPU with 'march='. Somehow MIDI works on startup while with the father it doesn't (i have to check 'MIDI settings' each time). Sometimes it gets temporarily frozen where the father doesn't, for example upon editing, saving, and then closing a simple subpatch (no GOP, no externals in it), and then it throws out all the output that was delayed during the freeze - this doesn't happen with the father (afaik you need to use -nosleep to make it behave like this?), and throws some 'error: .x123456: no such object's. The GUI is pretty.
Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
No, i wouldn't! I just had a vague memory that this behaviour (doing all the delayed calculations at once after a freeze) resembles -nosleep's behaviour (doing all the delayed calculations at once after a system sleep), but i may completely mistaken.
Andras
2010/11/26 Ivica Ico Bukvic ico@vt.edu
Why would you run it with nosleep? I am also not familiar with this option--what does it do?
András Murányi muranyia@gmail.com wrote:
Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both of
which
have changed as a result of accelerated drawing of iemgui objects. A simple recompile of mknob (and likely other objects that may rely upon the same framework) apparently fixed the problem.
Alrite, my knowledge is just not enough to teach moonlib (which i have
put
into /extra) where the pd headers are. What shall i modify in its
makefile?
CFLAGS = -DPD -I"../../src" -Wall -W -g
...and it works! I have lots of 'consistency check failed: glist_findrtext' when running, plus sometimes 'tcl/tk error: unknown encoding "yahoo"' on the terminal.
It
seems somewhat faster than the father, but that could also be that i've compiled it for my CPU with 'march='. Somehow MIDI works on startup while with the father it doesn't (i have to check 'MIDI settings' each time). Sometimes it gets temporarily frozen where the father doesn't, for example upon editing, saving, and then closing a simple subpatch (no GOP, no externals in it), and then it throws out all the output that was delayed during the freeze - this doesn't happen with the father (afaik you need to use -nosleep to make it behave like this?), and throws some 'error: .x123456: no such object's. The GUI is pretty.
Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
On Fri, 2010-11-26 at 02:44 +0100, András Murányi wrote:
No, i wouldn't! I just had a vague memory that this behaviour (doing all the delayed calculations at once after a freeze) resembles -nosleep's behaviour (doing all the delayed calculations at once after a system sleep), but i may completely mistaken.
I see. As it turns out I did discover consistency check errors which have to do with the new way iemgui objects tag their inlets and outlets to make them highlight-compliant. It seems that GOP-ed objects should not call glist_findrtext which is triggering this error as a bug (even though iemgui's new code gracefully falls back to a secondary option). I've now implemented a pre-check so that we never even call findrtext if we are an iemgui object drawn as part of GOP.
All this said, I've not encountered any burst-like slowdowns except when moving tons of objects simultaneously which was even more problematic in the old iteration due to the amount of socket traffic.
What is really weird is the following:
patch and try to move it around 2) in my case movement is rather choppy (understandably so as GOP even in l2ork iteration still relies upon coords calls rather than move-by-tagging) 3) *however*, when one selects and duplicates the same abstraction so that there are now two of them, suddenly performance is (at least on my machine--msi wind u100 with atom 1.6GHz procesor) amazingly smooth which goes against all logic
Anyone else experiencing the same and/or have a logical explanation for this?
Latest snapshot can be found in the usual place:
http://l2ork.music.vt.edu/main/?page_id=56
Cheers!
-nosleep means Pd doesn't let go of the CPU, so it means your
machine's CPU is more or less owned by Pd.
.hc
On Nov 25, 2010, at 8:30 PM, Ivica Ico Bukvic wrote:
Why would you run it with nosleep? I am also not familiar with this
option--what does it do?András Murányi muranyia@gmail.com wrote:
Namely, it appears mknob uses g_all_guis.h and g_canvas.h, both
of which have changed as a result of accelerated drawing of iemgui
objects. A simple recompile of mknob (and likely other objects that may rely
upon the same framework) apparently fixed the problem.Alrite, my knowledge is just not enough to teach moonlib (which i
have put into /extra) where the pd headers are. What shall i modify in its
makefile?CFLAGS = -DPD -I"../../src" -Wall -W -g
...and it works! I have lots of 'consistency check failed: glist_findrtext' when
running, plus sometimes 'tcl/tk error: unknown encoding "yahoo"' on the
terminal. It seems somewhat faster than the father, but that could also be that
i've compiled it for my CPU with 'march='. Somehow MIDI works on startup while with the father it doesn't (i
have to check 'MIDI settings' each time). Sometimes it gets temporarily frozen where the father doesn't, for
example upon editing, saving, and then closing a simple subpatch (no GOP, no externals in it), and then it throws out all the output that was
delayed during the freeze - this doesn't happen with the father (afaik you
need to use -nosleep to make it behave like this?), and throws some 'error: .x123456: no such object's. The GUI is pretty.Andras
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
"A cellphone to me is just an opportunity to be irritated wherever you
are." - Linus Torvalds