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.

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.

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.

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.