using [udpsend] with multiple data streams

kirsten murray's icon

Hi, I have a max msp patch which works (pasted below), that I would like to use with M4L.

The main patch receives data coming in from 12 sensors via the Arduino. [zl slice] separates the data into 12 patchers, which each contain an audio file that is manipulated using the incoming data.

The issues I'm having with transposing this to M4L are:

1) I'm creating a M4L device (a copy and paste of the max patchers) in each of 12 Ableton tracks to receive the data and manipulate the audio. I'm using [udpsend] to take data from each [zl slice] in the main patch and [udpreceive] to receive it in the M4L devices. I understand there is a way to use "---" which allocates a unique identifying number to each [udpsend] (without it, each [udpreceive] is receiving data from all of the sensors). But I'm unclear exactly how to do this...(have read the files/searched the forum/experimented with it - still unclear).

2) Alternatively, If I put the [udpsend] to receive directly from [fromsymbol] in the max msp patch, the data stream goes to [udpreceive] in M4L and shows in a message box, but [zl slice] from [udpreceive] doesn't work?

3) Is there any advantage/disadvantage to putting the main max patch in a M4L device (in it's own track in Ableton?), so I am only using M4L and Ableton, and not max msp as well.

Thanks

the token drawers max copy forum.maxpat
Max Patch

Source Audio's icon

I have looked into your patch.
If I were in your position, I would load the 12 tracks in Live
into slots 1 -12.
Then you know how to address each track by it's number.
for example by prepending an ID in the UDP string
It would not even need UDP to do so, just simple send - receive
if you decide to keep everything in Live.

It would be easy to get track id of each of device.
---------
the serial you use could be optimised.
200 ms refresh rate seems a bit slow
I would rather use fast sensor report and
prevent repeated values & slow down execution if needed.
The list with 13 values can be sent out
and each device extracts it's value depending on track number.
using for example zl.nth

kirsten murray's icon

Thanks @Source Audio. I've followed your suggestions and all works fine.
I'm assuming that using [zl.nth] objects rather than [zl slice] extracts the values more quickly as they work simultaneously rather than as production line?

Source Audio's icon

You could do both ways, I just found it simpler to send the full list, and let
receivers extract their value .
If more values were involved, then maybe different approach would be more efficient,
like splitting and forwarding,