Letraset Catalogue

I can't understand why my patch slows down when udpreceive receives continuous 'tactile' controller data from MRMR on iphone.

Can anyone offer any performance tips regarding OSC or udpreceive - or perhaps, a faster alternative to udpreceive.

I was also wondering if there's a way to communicate directly between iphone and my MacBook using OSC, where there's no wireless hub present - perhaps via a the computer-to-computer network setting.

Im on a MacBook Pro 17" Model MacBookPro1,2 with Leopard 10.5.8

I can't understand why my patch slows down when udpreceive receives continuous 'tactile' controller data from MRMR on iphone. 

 I was also wondering if there's a way to communicate directly between iphone and my MacBook using OSC, where there's no wireless hub present - perhaps via a the computer-to-computer network setting.

Im on a MacBook Pro 17" Model MacBookPro1,2  with Leopard 10.5.8

udpreceive-slowing-things-down-any-performance-tips-regarding-osc

What exactly do you mean when you say "why my patch slows down"?

When the UDP data comes in what are you doing with it?

Is what you are doing with it blocking the rest of the patch?

If so, then it will definitely slow your patch down.

What exactly do you mean when you say "why my patch slows down"?
What is it doing? 

When the UDP data comes in what are you doing with it?
Is what you are doing with it blocking the rest of the patch?
If so, then it will definitely slow your patch down.


I suspect UDP should be fast enough to deal with a single controller stream, unless its getting bogged down with large amounts of additional data and/or coming in pretty quickly leading to dropped packets - > check UDP maxqsize settings? Another possibility is that it is there are network issues leading to irregular or dropped data - using wireless hub now?

If neither of the above is the actual source of the problem, maybe the controller data is at such a rate that it is placing a significant load on the max scheduler depending on what your patch is trying to do with it the causing it to become unresponsive. If that is the case, an appropriately placed [speedlim] may help.

If neither of the above is the actual source of the problem, maybe the controller data is at such a rate that it is placing a significant load on the max scheduler depending on what your patch is trying to do with it the causing it to become unresponsive. If that is the case, an appropriately placed  [speedlim] may help.


I went through your suggestions but still saw this glitching in the associated jitter window, glitching I wasn't previously seeing with a mouse as input. Eventually I put a slide after udpreceive and the glitching disappeared - not a solution, but it seems point back at the incoming data network, MRMR or iphone.

Thanks.
 I went through your suggestions but still saw this glitching in the associated jitter window, glitching I wasn't previously seeing with a mouse as input. Eventually I put a slide after udpreceive and the glitching disappeared - not a solution, but it seems point back at the incoming data network, MRMR or iphone.


udpreceive slowing things down. Any performance tips regarding OSC?