decrease speed of messages? (non destructively)

newtfish's icon

Hi,

Im using udpsend and its locking up due to messages passing through very fast. Im wondering if there is a way to slow down the messages to udpsend?

Ive tried speedlim/qlim, but they simply destroy some of the messages. Im trying to keep all the messages, just slow them down.

Peter Castine's icon

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.

do.while's icon

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

Max Patch
Copy patch and select New From Clipboard in Max.
Lee's icon

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

newtfish's icon

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

Basvlk's icon

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?

Lee's icon

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

yonfell's icon

zl.queue
can also be helpful

best,
yonfell

do.while's icon

Hi !
@yonfell
actually very helpful !

Max Patch
Copy patch and select New From Clipboard in Max.

.
just to make sure

Christopher Dobrian's icon
Max Patch
Copy patch and select New From Clipboard in Max.

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.

Max Patch
Copy patch and select New From Clipboard in Max.

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

Max Patch
Copy patch and select New From Clipboard in Max.

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

Max Patch
Copy patch and select New From Clipboard in Max.

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

Lee's icon

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

Basvlk's icon

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