@alexandros This is working great, thanks so much!

Hello @whale-av Thanks again for your help. I'm looking again at the print out from my button and the digits are arriving separately. If I lift the receiver ONCE and the button reports multiple ones and zeroes they display like this when printed:
print: 1
print: 0
print: 1
print: 0
print: 1
So as I understand from your suggestions, although the first and last value is always good, I still need a window to just take the first (or last digit)? Is there a best object to do this? Thanks!

Hello! This is probably very simple stuff to most of you here, but it's got me stumped. I have installed a button on a toy phone installation in which the toy acts like a real phone. The button is sending a signal via pduino: at present when the phone is picked up a 1 is sent and when the phone is placed back on the hook a 0 is sent.

While debugging the patch I have discovered that the button I installed is actually sending a slew of ones and zeros in very quick succession when it is picked up, presumably as it transitions between being fully down and fully up. It typically looks like this if I print it: 1010101. The length is not consistent, although the initial 1 value is always correct.

Replacing the phone produces a more consistent single 0 value, although not always, sometimes it hiccups a 010. Typically though the first digit is the correct 0.

Is there a way to only respond to the first value and ignore the others? The closest equivalent to what I've experienced before is perhaps smoothing analog values when sensors are jittery, but I don't know how to go about doing it with digital 1/0 values. Thanks!

@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!

@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!

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

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.

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

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.

Amazing, thanks got it working! Always learning something new...