ctrlzjones

I get all of Lives transport data in an .amxd patch via [plugsync~].

I'd like to use some of this numbers (bars, beats, time signature, fired scenes) to organise things that are going on in my Max patch, outside of Live; therefore send them over ...

Sadly one cannot use [send] [receive] pairs for communicating between a Max patch that lives outside Live and a M4L patch, right? (why, oh why is that limitation present?)

I tried [udpsend] [udpreceive] but found that very unstable. There were constant crashes and the performance was slowing down heavily at unpredictable moments.

I switched to [sadam.udpsend] [sadam.udpreceive] and it seems to have timing glitches and it seems that the highest allowed number is 255 ...

And I also see that timing glitches (the interveral for 120bpm quarter beats oscillates between 482ms and 512ms, a different number each count).

So what is your preferred method of sending and receiving numbers from Live to Max and back again?

I switched to [sadam.udpsend] [sadam.udpreceive] and it seems to have timing glitches and it seems that the highest allowed number is 255 ...
And I also see that timing glitches (the interveral for 120bpm quarter beats oscillates between 482ms and 512ms, a different number each count).

So what is your preferred method of sending and receiving numbers from Live to Max and back again?


ableton-live-9s-transport-to-live-sadam-udpsend-limitations

you seem to be having network problems in general.

For reference we use udpsend/udpreceive as our master clock in my group. We broadcast every tick coming from transport, which is also being banged every tick.

We have very few latency issues, and they're mainly coming from my urge to change buffer settings in live every week, hehe.

you seem to be having network problems in general. 

We have very few latency issues, and they're mainly coming from my urge to change buffer settings in live every week, hehe.


I've noticed that the time accuracy of udpsend/udpreceive depends on Live's audio buffer size. So to minimize latency and jitter, the buffer should be as small as possible.

Shrinking Lives buffer increases its cpu load up to 20% in an empty project, something I'd rather not choose to go with.

So I left the [sadam.udp]'s, went back to proprietary [udp] objects and capture the information from [transport] instead from [plugin~].

It still has its jitters, but when I do all the timing calculations in the M4L patch and then send the results over, it is a fixed reliable number …

Instead when I send the 'raw infos' over into the .maxpat the ms coming from timing the beats are oscillating +/-5ms.

Shrinking Lives buffer increases its cpu load up to 20% in an empty project, something I'd rather not choose to go with. 

So I left the [sadam.udp]'s, went back to proprietary [udp] objects and capture the information from [transport] instead from [plugin~].
It still has its jitters, but when I do all the timing calculations in the M4L patch and then send the results over, it is a fixed reliable number …

Instead when I send the 'raw infos' over into the .maxpat the ms coming from timing the beats are oscillating +/-5ms.


FYI, the networking tools in The sadam Library send byte streams. The reason for 'being limited to 255' is that the objects are sending/receiving binary data; the actual bytes, when 'translated' to Max, are encoded as integers between 0 and 255.

To send custom data, you need to convert it first into a binary stream. Perhaps the easiest way to do this is by using the [atoi] and [itoa] objects for encoding/decoding, respectively:

Ableton Live 9's transport to Live/ sadam.udpsend limitations