coll and threads

Sep 22, 2010 at 5:59am

coll and threads

Does anyone have experiences with using many colls in a patch ?

I have just optimized a patch by removing all unnessecary UI objects and therefore I replaced all the hidden umenus with colls. Some are referring to the same and others are independent.

After this change I have experienced some thread / stack problems that I never had before. The patch has been used for many performances and has performed flawlessly (knock under table !!!)

Is coll a “slow” object concerning fast data retrieval ?


Sep 22, 2010 at 8:04pm

I have just investigated the population of colls in my patch and realized that I have a couple that are being dynamically modified while writing video via jit.qt.record and recording audio to a buffer.

I use the the colls to contain the postition and scale data for my 8 GL videoplanes.
I used to have hidden umenus for this job and it did’nt cause main thread crash problems.
Could this be the coll problem ?
Is there a thread bug in coll ?

all the very best,


Sep 23, 2010 at 6:36am

Hello Thomas Sandberg,

could you isolate the bug and post a patch ?

I ofen use [coll] to process [jit.matrix] in high priority thread without any problem since i get data with [jit.qfaker] … are you experienced “crash” or a bad patch functioning ?

Sep 23, 2010 at 9:36am

> Is coll a “slow” object concerning fast data retrieval ?

I would say yes, but i don’t know your patch.
In the case that you are using coll for numerical values, there are really faster ways : See few efficiency tests on coll in my “Efficiency-test-on-arrays.pat”, attached to the first message in this topic :

Sep 24, 2010 at 4:04pm

I have just realized that it isn´t the colls that were the main problem.
I replaced them with umenus which I have used before (without problems) – and I still got a heavy crash in the main thread as the report says.

During my optimization of the whole patch I have somehow messed up the order of operations. Probably deleting some trigger objects or changed the order of messages !

I was actually sending the following messages at the same time:
“clear and resize 8 buffer objects”,
“dispose 8 QT videos”,
“erase a folder”,
“create a new folder”
“16 GL messages”

Isn’t this a good reason for the crash ?

I have a feeling that especially the last line of Open GL messages was the main crash course since I did’nt get a crash isolating them from the message order and sending them manually .

But now I have created a better row of operations using trigger objects, message dumps,delays and deferlow messages and it seems to work (several knocks on wood !!).

BTW – I can really recommend this brilliant article by Arne Eigenfeldt about structuring a patch.

@pizza olives: It would’nt make sense if I posted the patch since it is huge and you would have to spend a lot of time trying to navigate in it. But I will definetely share with this very generous forum when it is more readable.

@Alexandre: Thanks for your effiency test patch and info about the coll speed.


Sep 24, 2010 at 4:27pm

Hello Thomas Sandberg,

IMHO : 99% bugs come from :

- order (so that’s a good habit to use massively [trigger]) ;
- from high/low priority management ;

speed/performance/CPU etc … is lost time … except in dev forum ;-)

Sep 24, 2010 at 9:02pm

I am sure you are right !!!

BTW – I found a brilliant article on the subject by Joshua Kit Clayton here:

In the article he mentions a patch that was included in Max 4 called Performance Options. I can’t find it in the Max 5 folders. Is it still included or does it have another name ?

Sep 24, 2010 at 11:38pm

The Performance Options patch has been integrated into the Preferences under the Scheduler tab.


You must be logged in to reply to this topic.