Cycling 74 » Topic: jit.gl.sketch dynamic changes in cmdlist

jit.gl.sketch dynamic changes in cmdlist

Brecht — Sun, 23 Apr 2006 15:47:42 +0000

My turn to ask a question :)

In the patch below I alter the position of 8 points of in a jit.gl.sketch. I do this using cmd_replace but this seems to be the cause of some slowing down when the changes are happening. Any hints on this ? Or is this the perfect case to start learning javascript and related jitter object…

#P user hslider 152 36 18 128 128 1 0 0;
#P window setfont “Sans Serif” 9.;
#P window linecount 1;
#P newex 122 108 73 196617 pak 0. 0. 0. 0.;
#P newex 228 85 34 196617 * -1.;
#P newex 122 85 34 196617 * -1.;
#P window linecount 8;
#P message 512 132 184 196617 cmd_replace 2 glvertex -1. $1 0. , cmd_replace 4 glvertex $4 0.75 0. , cmd_replace 7 glvertex 1. $1 0. , cmd_replace 9 glvertex $3 0.75 0. , cmd_replace 12 glvertex -1. $2 0. , cmd_replace 14 glvertex $4 -0.75 0. , cmd_replace 17 glvertex 1. $2 0. , cmd_replace 19 glvertex $3 -0.75 0.;
#P window linecount 1;
#P newex 261 236 85 196617 jit.gl.sketch test;
#P window linecount 5;
#P message 122 168 389 196617 reset , blend_enable 1 , glcolor 1. 1. 1. , glbegin line_strip , glvertex -1. 0.65 0. , glvertex -1. 0.75 0. , glvertex -0.9 0.75 0. , glend , glbegin line_strip , glvertex 1. 0.65 0. , glvertex 1. 0.75 0. , glvertex 0.9 0.75 0. , glend , glbegin line_strip , glvertex -1. -0.65 0. , glvertex -1. -0.75 0. , glvertex -0.9 -0.75 0. , glend , glbegin line_strip , glvertex 1. -0.65 0. , glvertex 1. -0.75 0. , glvertex 0.9 -0.75 0. , glend;
#P window linecount 1;
#P newex 23 236 79 196617 jit.window test;
#P toggle 25 110 15 0;
#P newex 25 160 58 196617 t b b erase;
#P newex 25 134 57 196617 qmetro 20;
#P newex 25 201 86 196617 jit.gl.render test;
#P newex 258 62 98 196617 zmap 0 127 -0.9 0.;
#P newex 152 62 104 196617 zmap 0 127 -0.65 0.;
#P connect 13 0 0 0;
#P fasten 13 0 1 0 157 58 263 58;
#P fasten 1 0 12 3 263 106 190 106;
#P fasten 1 0 11 0 263 82 233 82;
#P fasten 0 0 10 0 157 82 127 82;
#P fasten 0 0 12 1 157 104 148 104;
#P fasten 12 0 9 0 127 128 517 128;
#P fasten 11 0 12 2 233 104 169 104;
#P connect 10 0 12 0;
#P fasten 9 0 8 0 517 234 266 234;
#P fasten 7 0 8 0 127 234 266 234;
#P fasten 4 2 2 0 78 189 30 189;
#P connect 4 0 2 0;
#P connect 3 0 4 0;
#P connect 5 0 3 0;
#P window clipboard copycount 14;

Re: jit.gl.sketch dynamic changes in cmdlist

jasch — Sun, 23 Apr 2006 16:03:08 +0000

what happens if you change from pak to pack ?

/*j

Re: jit.gl.sketch dynamic changes in cmdlist

Brecht — Sun, 23 Apr 2006 16:27:40 +0000

Goes much better (probably 4x as much ;) ), still the occasional
hiccup in the underlaying render but almost negligable.
I’ve gotten so used to almost always using pak that I completely
overlooked pack.
Though it is just meant to add “sexyness” to an interface layer, i
can do without when push comes to shove, but I’d rather not of course
since it’s those little details that add a lot to the experience.

Thx Jasch.

Re: jit.gl.sketch dynamic changes in cmdlist

Brecht — Sun, 23 Apr 2006 19:36:38 +0000

sorry for this double post. Don’t know why that happened. Brought
‘puter back from sleep and mail goes off re-sending mail.

Re: jit.gl.sketch dynamic changes in cmdlist

Brecht — Tue, 02 May 2006 20:07:23 +0000

When implementing the cmdlist changes in a larger patch all worked fine.
Now, when I open the patch on a PC, instead of Mac, the patch seems to crash on this.
I have narrowed the problem down to the part where :

a counter is activated when a certain logical condition is met.
The counter runs up and changes 8 vertextpositions using the countervalue mapped onto the appropriate float values for the vertices.(using scale or zmap give the same result).

When this process is set in motion, the vertices start moving and then stall. Resulting in a full stalling of max…

Machine :
AMD sempron 2500+
1.75Ghz
512 Mb ram

XP professinal, service pack 1

NVIDIA GeForce3

I haven’t got the correct java version installed, which results in some error messages when starting up max, but I presume these are unrelated. I’m in no need for javasupport anyways.

Could this be because of the nr. of cmd_replace messages sent?

rgds,
B.

Re: jit.gl.sketch dynamic changes in cmdlist

Joshua Kit Clayton — Wed, 03 May 2006 09:24:45 +0000

Sounds like you are either backlogging the scheduler/queue (make sure
you drive with qmetro rather than metro), or you are growind your
cmd_list infinitely.

-Joshua

Re: jit.gl.sketch dynamic changes in cmdlist

Brecht — Wed, 03 May 2006 23:17:11 +0000

Alrighty.. I’ll give it a go keeping that in mind.
Only strange thing that strikes me, is that this problem does not occur under OS X with the same patch…

Re: jit.gl.sketch dynamic changes in cmdlist

vade — Thu, 04 May 2006 01:01:10 +0000

maybe run the patch and keep it open for a long time, like a few
hours, and you can see if the patch begins to slow down, and check
the cmd_list to see if , indeed, it has grown thus fucking things up?
Might not explain the PC crash, but.. eh.. *shrug*

its brute force, but hey..

v a d e //

http://www.vade.info
abstrakt.vade.info

Re: jit.gl.sketch dynamic changes in cmdlist

Brecht — Sat, 06 May 2006 01:05:43 +0000

As suggested by Joshua, I’ve separated the cmdlist changes to be
triggered by a qmetro. I haven’t been able to check what exactly the
problem was, but I suspect it was due to the fact that is was
triggered by a logical operator, which in turn was triggered by,
well, stuff happening continuously really… I guess the cmdlist
didn’t know how to handle this on windows… or on mac it was a bit
more ‘leeway’.