Forums > MaxMSP

difference between bangs from gui and automated bangs

July 14, 2008 | 8:11 pm

came across some strange behaviour when writing an external and wondered if anyone can shed some light on it.

i’m doing something like this at one point in the external, in a method triggered by a message:

post("starting, buffer size is %d",b2->b_size);
SETFLOAT((&sizearg),size);
typedmess((void *)b2, gensym("size"), 1, &sizearg);
while (b2->b_inuse != 0);//any kind of multithreading going on?
post("bufcopy~: size set to %f (%d)",size,b2->b_size);

then, in a patch, if i bang a message into it by clicking on the message or a bang going into the message, everything works fine, i get output like this:

starting, buffer size is 44
size set to 219.500000 (9679)
done, new buffer size is 9679

BUT… if the message is banged by something "automated", like a metro or if i click on a bang which goes through a delay then hits the message, i get the following (even though the message going into the external is identical):

starting, buffer size is 44
size set to 219.500000 (44)
done, new buffer size is 44

i’m really stuck, i don’t see how the source of a bang can make a difference in this way.


July 14, 2008 | 8:51 pm

Not sure how to fix your specific problem. I have had issues like this before and it usually turned out to be the difference between the high priority thread and the low priority thread. GUI is low, metro/delay is high. That most likely explains the difference in behavior you are seeing.

If you want to know more, search around for "scheduler priority", and maybe check out this article: http://www.cycling74.com/story/2005/5/2/133649/9742


July 14, 2008 | 8:55 pm

Actually I might know how to fix your problem. If you put a [deferlow] before your object, does that fix it? If deferring to the low priority thread is ok for your situation, then you should be able to deferlow in your code and prevent any issues with metro/delayed bangs.


July 14, 2008 | 11:58 pm

wow, it works! thanks very much.

can’t get my head round why it works though. if the message comes with high priority then it forces the resize to wait until the rest of the function is finished?


July 15, 2008 | 12:10 am

Quote: peterworth@gmail.com wrote on Mon, 14 July 2008 16:58
—————————————————-
> if the message comes with high priority then it forces the resize to wait until the rest of the function is finished?

It’s not exactly "forcing" the resize to wait, it’s just the resize takes longer and occurs at a lower priority. Probably the resize is an expensive operation, so it occurs at a lower priority to avoid briefly hanging Max and causing the scheduler to get out of sync. While the resize is happening, Max continues processing high priority events.

I don’t know if this is actually true, just making an educated guess based on the behavior we can see as users.


July 15, 2008 | 12:35 am

makes sense that. thanks again.


Viewing 6 posts - 1 through 6 (of 6 total)