Forums > MaxMSP

decrease speed of messages? (non destructively)

March 24, 2014 | 9:00 am

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.


March 24, 2014 | 10:27 am

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.


March 24, 2014 | 11:08 am

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

– Pasted Max Patch, click to expand. –


Lee
March 24, 2014 | 11:29 am

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…


March 24, 2014 | 5:37 pm

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


March 24, 2014 | 7:07 pm

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
March 25, 2014 | 1:08 am

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


March 25, 2014 | 4:30 am

zl.queue
can also be helpful

best,
yonfell


March 25, 2014 | 4:48 am

Hi !
@yonfell
actually very helpful !

– Pasted Max Patch, click to expand. –

.
just to make sure


March 25, 2014 | 8:53 am

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

– Pasted Max Patch, click to expand. –

</code>

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

– Pasted Max Patch, click to expand. –

</code>

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

– Pasted Max Patch, click to expand. –

</code>

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

– Pasted Max Patch, click to expand. –

</code>



Lee
March 25, 2014 | 9:57 am

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


March 27, 2014 | 4:12 pm

thanks Lee, thanks Christopher – I’m going to try Christopher’s abstraction to throttle the messages to touchosc


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