decrease speed of messages? (non destructively)

    Mar 24 2014 | 4:00 pm
    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.

    • Mar 24 2014 | 5:27 pm
      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.
    • Mar 24 2014 | 6:08 pm
      Hi !
      Peter has very good idea about stacking messages
      here is more less what Peter has suggested
    • Mar 24 2014 | 6:29 pm
      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...
    • Mar 25 2014 | 12:37 am
      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 :)
    • Mar 25 2014 | 2:07 am
      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?
    • Mar 25 2014 | 8: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
    • Mar 25 2014 | 11:30 am
      can also be helpful
    • Mar 25 2014 | 11:48 am
      Hi !
      actually very helpful !
      just to make sure
    • Mar 25 2014 | 3:53 pm
      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.
    • Mar 25 2014 | 4:57 pm
      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
    • Mar 27 2014 | 11:12 pm
      thanks Lee, thanks Christopher - I'm going to try Christopher's abstraction to throttle the messages to touchosc