I have a patch with Comport communicating with an Arduino. The Arduino is supposed to send a 13 when a particular button is pushed down and a 33 when the button comes back up. This works perfectly when I run PD on a MacBook. When I run it on a Rasberry pi though, it sends 10 instead of 13 (the 33 works fine). When I changed the Arduino code to have it send a 40 instead of a 13, then it all works fine. When I changed it back to a 13 though, the PI starts reading 10s again. I CANNOT figure out why this would be. I'm able to use the workaround of just picking a different number than 13, but at this point I'm just curious. Why would this be?

@Tombot7 It is sending the decimal value of ASCII characters....... not floats.
ASCII 13 is "carriage return" and ASCII 10 is "line feed".
They are reserved characters (all decimal values 0-31) are functions and do not print).
13 and 10 are nearly the same thing but not exactly...... "line feed" does not return the cursor to the start of the new line.
Anyway, I am surprised at the translation as I would expect the same UNIX behaviour on a Mac and an RPI. I have no idea why the RPI would change the value.
Of course you receive the decimal values as integers and can use them as such in Pd.
David.

That's fascinating that Mac and Linux would handle that differently. I've been using comport x 2succesfsully to run two different Arduinos through PD on Linux on my last project and it's worked great. I did not however happen to use the number 13 though. I was doing it the exact same way for this project but had been doing the testing and uploading on a mac... then when I went to implement it with the pi ran into this. Wow! Thank you!

@Tombot7 It likely is the same between OSX and most linux distros, I would expect this is a raspbian thing and possibly a bug.

Depending on the hardware, I sometimes get a 10 instead of a 13 on my Linux machine too. Haven't really spotted what combination of hardware creates this, and the late Martin Peach (who wrote [comport]) was not aware of anything that might be causing this in his object, because, as he wrote in Pd's mailing list, [comport] doesn't interpret anything.
I even covered this issue in my [serial_print] abstraction found here https://github.com/alexdrymonitis/Arduino_Pd
There's a [serial_print13] version to address this issue, where 13 is printed as 10 (so when Serial.println() is used, Pd receives 10 twice, instead of a 13 and a 10).

Martin Peach (who wrote [comport])

[comport] has been written by Winfried Ritsch.

Funnily enough, someone else has already brought up this issue in the past (https://lists.puredata.info/pipermail/pd-list/2019-05/125271.html) and I even came up with a fix, but then forgot to make a PR . I found the git branch with the fix on my laptop, so I can do that later this day. Will post a link to the PR here.

@Spacechild1 said:

Martin Peach (who wrote [comport])

[comport] has been written by Winfried Ritsch.

Oops, sorry for the misinformation... thanks for pointing it out!

Here is the PR: https://git.iem.at/pd/comport/-/merge_requests/1

In the meantime, you can grab the following branch and build from source: https://git.iem.at/ressi/comport/-/tree/input-fix

I’m in the process of eliminating Comport entirely and using MIDI USB devices instead - same hardware but reprogramming the arduinos. I’m hoping it will make things faster for pure data but also hoping it will mean I can use those same hardware devices with other computers as MIDI devices that can be free of their parent so to speak.

Any thoughts on whether a rasberry pi running pure data will be faster handling incoming USB midi signals as opposed to two instances of comport?

MIDI transfers data at a specific baud rate, namely 31250. The Teensy (or Arduino) can run at much faster baud rates, plus you can create your own protocol and transfer values with a greater resolution than the 7-bit of MIDI 1.0. Personal experience has shown that using the Teensy with Serial.write() is way faster than MIDI. You can probably send values with greater resolution that 7-bits by breaking them down in the Teensy code and re-assembling them in Pd, but if you are to use your project with other hardware or software than communicate with MIDI, then I'm not sure how this would be possible.

The best solution, from my point of view, is to use Teensy, but instead of using Serial.print() and Serial.println(), use Serial.write() and avoid sending 13. In case a 13 is supposed to be sent, but Pd receives 10, the Teensy should somehow notify Pd that this has happened, probably with a byte in the range 128-255, that functions as a tag. Then Pd can remedy this.

PSA: comport v1.2 has been released and is available on Deken. This issue should be resolved now. Please test!