It's a little tricky because if messages are, in the long run, coming faster than you can handle them, there's a potential risk that your intermediary buffer will grow towards infinity. At least in theory.

In practice, this is hopefully not a real danger.

A solution would be to simply store the incoming messages in, say, a coll and while the coll is not empty to bang out one message at a time at a rate that udpsend can handle. Hopefully the coll will go completely empty once in a while, so you need to test for that and stop the metro (or whatever you use to extract messages from the coll).

Requires a bit of patching. Let us know if you need help, but perhaps this pointer is enough.

Hi ! Peter has very good idea about stacking messages here is more less what Peter has suggested

are you getting any messages in the MAX window?

udpsend is non-blocking and will essentially queue a message and return to you immediately as it does not wait for any response from the recipient

the default queuesize is 512 and can be changed with the maxqueuesize attribute...

basically, if you're not getting any messages in the MAX window saying that messages are being dropped due to queuesize being exceeded, then this is unlikely to be your issue...

Thanks peter and do while, great stuff. Cheers Lee I upped the queuesize and it helps a bit, still a long way to go to optimise, but every bit helps :)

I suspect I have a similar problem: I don't see any issues in max (newtfish, you say udpsend 'locks up' - do you get an error message?)

but sometimes my TouchOSC doesn't receive all the updates, and sometimes it crashes which I suppose could also be due to too many updates.

I like DO...WHILE's patch but it seems a bit big.. is there no simpler solution?

In principle it's the same thing the audio buffer in your computer does right?

Have to say TouchOSC is a bit flakey it seems, esp when sending lots of data to it. You really need to send OSC bundle messages to it if you want to send constant rapid updates - even then it still drops the odd update unless using core MIDI

zl.queue can also be helpful

best, yonfell

Hi ! @yonfell actually very helpful !

. just to make sure

Here's an abstraction that will do what you want, provided your messages are single items (int, float, symbol) or lists that you want broken up into single items.

If you save the above patch with the name "timeditems", then this next patch will demonstrate it.

If you need something that queues lists and other multi-item messages, then you'll need to use something more like this.

If you save that with the name "timedmessages", you can test it with this patch.

newfish, if this is related to your other post on js updates from m4l remember that the slow portion of the process is from python into max and throttling your udp output is not going to make any difference

thanks Lee, thanks Christopher - I'm going to try Christopher's abstraction to throttle the messages to touchosc