Brecht

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...

jit-gl-sketch-dynamic-changes-in-cmdlist

what happens if you change from pak to pack ?

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 

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.

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.

sorry for this double post. Don't know why that happened. Brought 

'puter back from sleep and mail goes off re-sending mail.

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


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...

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?

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).

Machine : 
AMD sempron 2500+
1.75Ghz
512 Mb ram

Sounds like you are either backlogging the scheduler/queue (make sure 

you drive with qmetro rather than metro), or you are growind your 

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.

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...

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...


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*

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*

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 

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'.


jit.gl.sketch dynamic changes in cmdlist