Hello all, I've been looking around and cannot find the info I'm looking for, so I hope you'll indulge this post.
I am creating an audio installation for an art gallery that will be run from PD patches on multiple Raspberry Pi computers. I have 8 channel interfaces running on each Pi, and I don't want the different sound installation elements to play over each other. So, I would like to have the completion of playback on Pi1 to trigger playback on Pi2, and vice versa.
This will be the first time I have used more than one Pi for a project, and while I have some idea of how I might connect them, I am struggling to identify the best way that also works well for Pure Data.
As I said, at the very least I want a simple trigger mechanism between patches running separately on each Pi, but if there's a way to send more useful data I would be interested in that also- I just may not be quite ready for a lot of complexity yet!
I have experience with pduino and arduino nanos as ways of getting data in and out of PD - this may be one way to do it, but I suspect there might be an easier way? Is this where I should be using comport?
Thanks y'all, this community is so useful.

Also, I/O hardware seemed the best place for this, but if I should post this question elsewhere, please let me know! Thanks

@Dizzy-Dizzy Technical Issues is probably the best place.
You can send data across a network between computers running Pd.
Wi-Fi is plenty fast enough for the data you will be sending and the [netsend] and [netreceive] objects are built into Vanilla Pd.
Probably best to fix the IP addresses of your RPI's just in case a new address is given by the router at the end of a lease.
I will move your thread.
David.

Thanks David, really appreciate it!
I will definitely play with the netsend/netreceive objects, but a lot of the spaces I install in don't have wi-fi, so it would be really useful to know the best way to hardwire these connections.
As I mentioned I have a few arduino nanos flashed with firmata and ready to go if this would do it, although maybe there is a neater way?
All the stuff I dig up on the internet doesn't take PD into account, so I'm struggling to find a clear path forward.

@Dizzy-Dizzy I wouldn't recommend using the venue Wi-Fi anyway.
You can hard wire them through their network cards (Ethernet ports). That is "maybe" more reliable.... but I run plenty of shows over Wi-Fi reliably.
You would need a router anyway to connect them all together...... and routers are usually 4 ports + Wi-Fi. A second hand Linksys is about 20€..... the WRT54 series are very reliable.

A router would be a good investment for the future, when you are running 200 RPI's at once.
Another advantage would be that you can set the RPI's up easily with your laptop if you connect to the same network and use a VNC client.

Someone else will have to help for the Pduino's..... I have no knowledge about them.
Lot's to think about....... but time for bed....
David.

Thanks again, David. I'm in the USA so I trust you are sleeping soundly somewhere in the EU. I've been toying with the netsend/netreceive objects and I have them doing exactly what I wanted, so I'm going to continue to follow your advice and will pick up a router this week, to experiment with getting them connected that way - there's a WRT54 selling second-hand in my area for $10!
Ben

You can also connect the two Pis straight without a router (in case they are only two) and set static IP addresses. If more than two, then a router or an ethernet switch will be necessary.

@alexandros Do you mean 'connect' with an ethernet cable? Either way, I'm interested in all the ways I could make this work, do you have any resources or more details you can share?
@whale-av Thanks again for all your suggestions! I have picked up a WRT54GS router, and have 2 RPis communicating successfully with the netsend/netreceive objects, with one playing an audio file then sending a message to trigger audio playback on the other RPi, which then sends a trigger message back to the first RPi, and so on and so on.
However, I'm having trouble maintaining that connection. I left them running last night in my studio and when I came in today they had stopped running. One of the two RPi PD consoles had reported "recv (tcp): Network is unreachable (101)".
I need playback to function on a loop without interruption until I trigger a shutdown at a specific time - any tips to improve and maintain the connection and make it fail-safe?
Thank you!

Yes, I mean connect with an Ethernet cable. You can look up how to set a static IP on the Pi, and make sure both Pis share the same first three fields of this address, for example, the first Pi could have 192.168.100.100 and the second 192.168.100.101. This way they can connect with each other and communicate over OSC.

@Dizzy-Dizzy Yes, @alexandros means connect them with an Ethernet cable. You will not be able to connect another computer though.... the 2 rpi's will just talk to each other.

You should set the rpi's to use static ip addresses anyway..... and they must be different..!
The home/etc/dhcpcd.conf files should look something like this....... dhcpcd.conf ..... which is set to use wifi and to fall back to Ethernet.... so the fallback should be commented out for your setup..... unless of course you are connecting them to the router with Ethernet cables...... in which case eth0 should be set as primary.

It will help if you post your Pd patches for the 2 rpi's and their home/etc/dhcpcd.conf files and their home/etc/wpa_supplicant/wpa_supplicant.conf files.
Zip them all up in a zip folder and upload them to this thread.

The router should not be connected to the internet..... so the NAT redirection can be turned off.
You can protect access to the router by MAC addresses (the Mac addresses of any device you want to use should be added to the table in the router) to try as far as possible to stop anyone else connecting to the wifi.
The ip addresses of the rpi's should be outside the range of the dhcp server of the router....... but the router dhcp server can be turned off anyway.

You want to be certain that the message passes between the rpi's so you should use TCP and not UDP for netsend/netrecieve.
Also there has been a discussion on the pdList about [netsend -u] dropping the socket so it is best avoided until fixed.
You could add a "fix" mechanism to your patch that makes sure the connection is good before playing anything and doing a disconnect + connect if it gets no reply.

David.

@alexandros Thanks for clarifying and for your help!

@whale-av Thanks David, this is really useful info. I will upload the patches tomorrow. I have set up unique static ip addresses for all of the pis, and they are all connected via an ethernet router.

NAT redirection is a new term to me, I shall look into turning it off, but the WIFI router I'm using is not connected to internet at present.

I haven't encountered TCP/UDP before, or [netsend -u], but some online searching is giving me the info I think I need to set everything up to use TCP only.

I will have a go at adding a "fix" mechanism before I upload the patches. Thanks again for all of your help!

@whale-av why use TCP if it's a local connection? Even if you connect the Pis through a router, UDP should be good, and it's faster. Why are you suggesting that packages could be dropped? I have never had any issues, whether computers were connected with or without a router in between, with static or DHCP addresses, all in the same local network.
I have also never had issues with [netsend -u -b] (@Dizzy-dizzy mind the -b flah, you'll need it for OSC).
Perhaps [udpsend] and [udpreceive] from the mrpeach library performs better?