Danny Fratina

I've got an Arduino device hooked up and everything is working great. It's usually reporting on port c, but every once in a while it shows up on a different port (usually d, but I'm also not sure what to expect with other computers), so every time I open the patch I have to print to console and manually ensure the correct port is set to go into the serial object. I was hoping to build an autodector that reads from the console and sets the serial object to the correct port as printed to the console, not only to save time when initializing the patch after opening but to build out a way to future-proof the patch for if it runs on a different computer and the Arduino is showing up on a different port.

It doesn't appear like there is a way to read data from the console—though let me know if I'm wrong. So in the meantime, I tried setting up a few different workarounds. My first attempt was to use the different outlets of serial object and combinations of "print" or "getport" messages. The problem here is that even with unpacking, I'm not getting the actual port letter, only the unpacked 

 of the correct message ("usbmodem1101"). As in, the console shows:

but the unpacked message within the patch coming from printing is simply:

The order is correct, but it does not specify the port. Which means that with some careful [sel] objects I can route towards sending the correct port to the serial object. As in, after unpacking, if the modem message comes out the 4th outlet, a [sel usbmodem1101] object spits out a "port c" message into the serial object. If it comes out of the 5th outlet, a copy of the sel object bangs to a "port d" message into the serial object, etc.

 with this is that it would require multiple possible port setups (all 26 letters, to be insanely safe), and if the "usbmodem1101" ever were to change (maybe a firmware update to Arduino? maybe it reads differently on different computers/operating systems?), this detection falls apart. It seems somewhat janky in general though, I somehow do not trust this setup, it seems easy to trip up and not work consistently, especially because I have to set the metro AFTER the correct port is initialized and I think there is a more compact and efficient way to do this.

My theory for what might be a safer solution: because the Arduino sends a gazillion numbers a second when the correct port is open, what if I have a loadbang on this little detector widget, and the widget says "if more than 1 second passes without another piece of data coming in after the initial bang, cycle to the next port message and test this again. if a bunch of data segments come in, this cycle completes because we're on the correct port." (I feel like the [change] object might be helpful here?)

One problem with this is that if the Arduino stutters for a second, the whole patch would basically come to a halt and need to be reinitialized? Not sure if this is a legit concern with Arduino, but maybe not important to consider for now.

 problem is that I cannot wrap my head around how to build the above concept. The full flow is: Because I know Max cannot detect 

 started. I've got two messages ("port c" and "port d") going into the serial object. I need to detect if that loadbang is followed by 

coming out of the serial object—if no, send one of the port messages into the serial object. If no again, try the other. Keep trying each until we get a yes, then STOP.

Any ideas on how to build this little module and/or if there is a better way to do serial port detection? Thanks so much in advance yall!

I've got an Arduino device hooked up and everything is working great. It's usually reporting on port c, but every once in a while it shows...

detecting-serial-port-and-workarounds

For this reason and other reasons I mainly use Open Sound Control with esp32 or an ethernetshield for data transmission in between a microcontroller and a computer.

on windows one has to read from max console.

but you have to provide something to match,

I mean like for that specific arduino "usbmodem"

ignoring number that can change depending on  USB

example on mac - you need to match "usbmodem" and grab either

port abbreviation or full port name, here port name used:

and device detector on windows, string to match (USB Serial Device) 

you need to detect your device depending on what part of it's name remains unchanged

You can set own USB indentifier to make it unique as well

as use it as midi or HID device, it depends on data you send.

Thank you for this detailed write up. I think your solution may work, but I have found one issue: the "usbmodem" is generally "usbmodem1101" BUT if I'm using a multiport (I have two USB-C ports and at home 3 things to plug in, so I plug them into a splitter thing to use all at once), then it shows up with a different number. More importantly, if I have an audio interface plugged in (what is listed on port c below), I've got two different "usbmodem" numbers to deal with at all times. This is what my current console printout reads with just the arduino and interface plugged in:

So when I follow your first diagram, it totally works if only the arduino is plugged in. But adding the interface or splitter kind of bricks it.  Any suggestions?

your audio interface shows as usbmodem device ?

anyway, if that ghost audio interface has longer string then arduino,

But I can't help you without details on what exactly needs to be matched,

or better say what should one have to deal with in all possible plug scenarios.

And - what do you really capture from arduino ?

What model is it exactly, and could you use it as midi or HID device ?

here is a fix taking that audio interfaces has also

letters and not  only digits  included in usbmodem port name.

Maybe you could build something on top on this approach?

To answer your question, for whatever it's worth, my arduino (Arduino Nano 33 BLE Sense Rev2 with headers) device is giving me data from an accelerometer, gyroscope, magnometer, and a color sensor (all of which give data as three different outputs). For now this will be mac only, but I will eventually like to test this on Windows computers. I've affixed it to my instrument to capture motion data.

On windows you have to use console, because serial does not output device

Device naming could be different then on mac.

Detecting serial port and workarounds