So, neither the OS nor the Pd or [comport] version seem to make any
difference.
check my last two mails, I think this is macOS/Linux issue. can you try my fix?
Gesendet: Dienstag, 14. Mai 2019 um 13:07 Uhr Von: "Ingo" ingo@miamiwave.com An: 'Ingo' ingo@miamiwave.com, "'Roman Haefeli'" reduzent@gmail.com, adrcki@gmail.com, itensimon@gmail.com, pd-list@lists.iem.at Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
I just tested this on another OS.
My older system that did it was a relatively old Ubuntu 11.10 still using the older [comport] object with Pd-Extended. Now I tested with a rather new Debian (9.5 / 32bit) and a recent Pd (0.48) with the latest [comport] object.
Both behave the same way.
If I send a MIDI program change from my EWI to the USB (-MIDI) input I get the correct program number. If I use the MIDI Din cable going from the EWI into my Arduino MIDI interface I get MIDI program #11 instead of #14 (counting from 1-128!). Still the number 13 gets replaced with 10.
This time the Arduino is a Arduino Micro and not a ProMicro with a different programming.
So, neither the OS nor the Pd or [comport] version seem to make any difference.
Ingo
-----Original Message----- From: Ingo [mailto:ingo@miamiwave.com] Sent: Tuesday, May 14, 2019 12:36 PM To: 'Ingo'; 'Roman Haefeli'; pd-list@lists.iem.at Subject: RE: [PD] Comport problem with Arduino: 13 is coming in as 10
Sorry, this was meant to be: Carriage Return is 13. Line Feed is 10 (not 0x10).
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Ingo Sent: Tuesday, May 14, 2019 12:31 PM To: 'Roman Haefeli'; pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
The strange thing is that I'm using 2 Arduino ProMicro.
Sometimes one does it and the other one is fine. Next time both of them do it and next time none of them. It's completely unpredictable. The same Arduino sends the same data that gets interpreted differently when I reopen Pd. So I wouldn't blame the Arduino in this case. I don't expect it to send different values upon reopening Pd. (I'm not sure if I did a hardware restart in between - I'll have to observe this.)
However, the Pd programming hasn't changed either ... I know there is some sort of modem code that replaced 13 with 10. Carriage Return is 13. Line Feed is 0x10. In some cases The Carriage Return is either followed or even replaced by Line Feed. It looks like this is happening here.
The question is: How can I control this type of Carriage Return
behavior?
I don not my Arduino to be handled as an old modem ...
I have tried Serial.write(13) and Serial.print((char)13) and they both output 10 in Pd. The work-around I have figured to this is to write a second byte after every value I send, and in case of sending a 13, send a unique value to this second byte, so that Pd knows it should be receiving a 13. It's double the load but in most cases it shouldn't be a problem, especially when writing raw bytes with
Serial.write().
I have already a bunch of units out with the same hardware. So changing the programming on the Arduino is not necessarily the best choice.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Roman Haefeli Sent: Tuesday, May 14, 2019 11:38 AM To: pd-list@lists.iem.at Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
On 14/5/19 9:45 p. ., Roman Haefeli wrote:
Hi Ingo
On Tue, 2019-05-14 at 07:38 +0200, Ingo wrote: > I'm getting number 10 instead of 13 from my adruino.
This sounds somehow familiar to me, but I can't recall the exact details of the issue nor am I able to find something about it on the web.
Have you ruled out any other source besides [comport]? Can you print the data with some other tool to make sure that the Arduino is not messing up the bytes 10 and 13? If it indeed [comport] is the culprit, then it should be quite easy to fix, but then again there we probably would find code that does the translation. I am not sure such code exists.
I have been having the same issue for quite some time now, and have posted it in this list in the past.
Have you ruled out any other culprit? Have checked what is sent with some means other than [comport], for instance with the Arduino IDE? I don't have an Arduino at hand, so I don't know the exact procedure, but maybe there is a way to print data as hex values or so.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list