Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Christof Ressi]

here's a fork containing the fix: 
https://git.iem.at/ressi/comport/tree/input-fix - completely untested! :-) I 
won't be able two test myself for the next 2 weeks, so no need to rush.

> Gesendet: Dienstag, 14. Mai 2019 um 13:56 Uhr
> Von: "Roman Haefeli" 
> An: pd-list@lists.iem.at
> Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
>
> On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
> > > > 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?
>
> Yeah, I will when I have access to an Arduino (or other serial device)
> and report back. Thanks for looking into this.
>
> 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

Re: [PD] Delay (msec) option in audio properties

[Miller Puckette]

Rough explanation:  Pd sets up two FIFOs, one for audio input and one for
output, and "delay" sets the length of those FIFOs.  I/O is managed so that
(in theory at least) the sum of the number of sample frames in the input
and the output FIFOs add up to the "delay", plus or minus one 64-saple block.

So theoretically at least, the total delay from audio input to output should
be the sum of three things: this number, the OS's internal audio latency
(which depends on all sorts of factors) and the A/D/A devices.

cheers
Miller

On Tue, May 14, 2019 at 07:22:55AM +0100, Mario Buoninfante wrote:
> Hi,
> 
> Can anyone explain me what's the actual effect of 'Delay (msec)' parameter
> you can find in the audio properties dialog?
> 
> Cheers,
> Mario

> ___
> 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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Christof Ressi]

> How could it be the Arduino code if everything works fine after I manually set
> the ttyACM0 to raw?

I think I've already explained that in my previous mails. now can you try the 
code changes I've suggested? if you're not sure, I can send you a patched 
version you can compile and test.

> Gesendet: Dienstag, 14. Mai 2019 um 17:53 Uhr
> Von: "Ingo" 
> An: "'Martin Peach'" 
> Cc: pd-list@lists.iem.at
> Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
>
> How could it be the Arduino code if everything works fine after I manually set
> the ttyACM0 to raw?
>
> I have made myself a workaround by now to set all Arduino ttyACM* to raw by
> sending
>
> stty -F /dev/ttyACM* raw
>
> to a [shell] object after starting up the patch.
>
> So the Arduino cannot be causing the problem. It's the [comport] object that
> does not correctly set to port to raw in "all" cases.
> Maye in most cases but not in "all" cases.
>
> Ingo
>
>
>
> From: Martin Peach [mailto:chakekat...@gmail.com]
> Sent: Tuesday, May 14, 2019 5:28 PM
> To: Ingo
> Cc: pd-list@lists.iem.at
> Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
>
> I ran this code on an arduino nano and sent it into a comport-print to verify
> that it passes all the values without change:
>
> void setup() {
>   Serial.begin(115200);
>   while(!Serial);
>   Serial.println("OK");
> }
>
> void loop() {
>   static uint8_t x = 0;
>   Serial.write(x);
>   delay(25);
>   x++;
> }
>
> Maybe you could try that to be sure it's not your arduino code that's doing
> it.
>
> Martin
>
> On Tue, May 14, 2019 at 11:14 AM Ingo  wrote:
> Whatever version was current in September 2018 is the version I have installed
> in the new setup.
> I wouldn't have been surprised about this behavior in the old version from
> 2011 - but 2018?
>
> I don't think there have been too many major changes since September 2018.
>
> As I had mentioned before: Sometimes it works - sometimes it doesn't .
>
> Ingo
>
>
>
> From: Pd-list [mailto:pd-list-boun...@lists.iem.at] On Behalf Of Martin Peach
> Sent: Tuesday, May 14, 2019 4:20 PM
> To: pd-list@lists.iem.at
> Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
>
> I just tried it here on both Windows 10 and Ubuntu with no issues. I can print
> every value from 0 to 255 from arduino and receive it unchanged in pd. I think
> possibly the OP is using an older version of comport.
>
> Martin
>
>
> On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig  wrote:
> On 14.05.19 15:47, Ingo wrote:
> > Could it be possible that the operating system does this even before it gets
> > to the comport object?
>
> well, those flags are supposed to control exactly what "the operating
> system does" in this respect.
>
> fgmasdr
> IOhannes
>
> ___
> 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
>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Ingo]

How could it be the Arduino code if everything works fine after I manually set 
the ttyACM0 to raw?

I have made myself a workaround by now to set all Arduino ttyACM* to raw by 
sending

stty -F /dev/ttyACM* raw

to a [shell] object after starting up the patch.

So the Arduino cannot be causing the problem. It's the [comport] object that 
does not correctly set to port to raw in "all" cases.
Maye in most cases but not in "all" cases.

Ingo



From: Martin Peach [mailto:chakekat...@gmail.com]
Sent: Tuesday, May 14, 2019 5:28 PM
To: Ingo
Cc: pd-list@lists.iem.at
Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10

I ran this code on an arduino nano and sent it into a comport-print to verify 
that it passes all the values without change:

void setup() {
  Serial.begin(115200);
  while(!Serial);
  Serial.println("OK");
}

void loop() {
  static uint8_t x = 0;
  Serial.write(x);
  delay(25);
  x++;
}

Maybe you could try that to be sure it's not your arduino code that's doing 
it.

Martin

On Tue, May 14, 2019 at 11:14 AM Ingo  wrote:
Whatever version was current in September 2018 is the version I have installed
in the new setup.
I wouldn't have been surprised about this behavior in the old version from
2011 - but 2018?

I don't think there have been too many major changes since September 2018.

As I had mentioned before: Sometimes it works - sometimes it doesn't .

Ingo



From: Pd-list [mailto:pd-list-boun...@lists.iem.at] On Behalf Of Martin Peach
Sent: Tuesday, May 14, 2019 4:20 PM
To: pd-list@lists.iem.at
Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10

I just tried it here on both Windows 10 and Ubuntu with no issues. I can print
every value from 0 to 255 from arduino and receive it unchanged in pd. I think
possibly the OP is using an older version of comport.

Martin


On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig  wrote:
On 14.05.19 15:47, Ingo wrote:
> Could it be possible that the operating system does this even before it gets
> to the comport object?

well, those flags are supposed to control exactly what "the operating
system does" in this respect.

fgmasdr
IOhannes

___
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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Martin Peach]

I ran this code on an arduino nano and sent it into a comport-print to
verify that it passes all the values without change:

void setup() {
  Serial.begin(115200);
  while(!Serial);
  Serial.println("OK");
}

void loop() {
  static uint8_t x = 0;
  Serial.write(x);
  delay(25);
  x++;
}

Maybe you could try that to be sure it's not your arduino code that's doing
it.

Martin

On Tue, May 14, 2019 at 11:14 AM Ingo  wrote:

> Whatever version was current in September 2018 is the version I have
> installed
> in the new setup.
> I wouldn't have been surprised about this behavior in the old version from
> 2011 - but 2018?
>
> I don't think there have been too many major changes since September 2018.
>
> As I had mentioned before: Sometimes it works - sometimes it doesn't .
>
> Ingo
>
>
>
> From: Pd-list [mailto:pd-list-boun...@lists.iem.at] On Behalf Of Martin
> Peach
> Sent: Tuesday, May 14, 2019 4:20 PM
> To: pd-list@lists.iem.at
> Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
>
> I just tried it here on both Windows 10 and Ubuntu with no issues. I can
> print
> every value from 0 to 255 from arduino and receive it unchanged in pd. I
> think
> possibly the OP is using an older version of comport.
>
> Martin
>
>
> On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig 
> wrote:
> On 14.05.19 15:47, Ingo wrote:
> > Could it be possible that the operating system does this even before it
> gets
> > to the comport object?
>
> well, those flags are supposed to control exactly what "the operating
> system does" in this respect.
>
> fgmasdr
> IOhannes
>
> ___
> 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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Ingo]

Whatever version was current in September 2018 is the version I have installed 
in the new setup.
I wouldn't have been surprised about this behavior in the old version from 
2011 - but 2018?

I don't think there have been too many major changes since September 2018.

As I had mentioned before: Sometimes it works - sometimes it doesn't .

Ingo



From: Pd-list [mailto:pd-list-boun...@lists.iem.at] On Behalf Of Martin Peach
Sent: Tuesday, May 14, 2019 4:20 PM
To: pd-list@lists.iem.at
Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10

I just tried it here on both Windows 10 and Ubuntu with no issues. I can print 
every value from 0 to 255 from arduino and receive it unchanged in pd. I think 
possibly the OP is using an older version of comport.

Martin


On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig  wrote:
On 14.05.19 15:47, Ingo wrote:
> Could it be possible that the operating system does this even before it gets
> to the comport object?

well, those flags are supposed to control exactly what "the operating
system does" in this respect.

fgmasdr
IOhannes

___
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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Christof Ressi]

> I think possibly the OP is using an older version of comport.

to quote Ingo:

> 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.
 
I think the behavior of [comport] basically depends on the (OS-specific) 
default value of c_iflag. if disabling ICANON alone was sufficient to disable 
all input processing, why would cfmakeraw set all those input flags?

there are other sources suggesting to disable ICRNL (additionally to ICANON): 
https://viewsourcecode.org/snaptoken/kilo/02.enteringRawMode.html

I'd say let's try cfmakeraw() and see if it solves Ingo's problem. @Ingo can 
you add the code and compile [comport] yourself or do you need help?

Christof

Gesendet: Dienstag, 14. Mai 2019 um 16:19 Uhr
Von: "Martin Peach" 
An: "pd-list@lists.iem.at" 
Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10

I just tried it here on both Windows 10 and Ubuntu with no issues. I can print 
every value from 0 to 255 from arduino and receive it unchanged in pd. I think 
possibly the OP is using an older version of comport.
 
Martin
  

On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig 
mailto:zmoel...@iem.at]> wrote:On 14.05.19 15:47, Ingo wrote:
> Could it be possible that the operating system does this even before it gets
> to the comport object?

well, those flags are supposed to control exactly what "the operating
system does" in this respect.

fgmasdr
IOhannes

___
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[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[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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Martin Peach]

I just tried it here on both Windows 10 and Ubuntu with no issues. I can
print every value from 0 to 255 from arduino and receive it unchanged in
pd. I think possibly the OP is using an older version of comport.

Martin


On Tue, May 14, 2019 at 10:03 AM IOhannes m zmoelnig 
wrote:

> On 14.05.19 15:47, Ingo wrote:
> > Could it be possible that the operating system does this even before it
> gets
> > to the comport object?
>
> well, those flags are supposed to control exactly what "the operating
> system does" in this respect.
>
> fgmasdr
> IOhannes
>
> ___
> 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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[IOhannes m zmoelnig]

On 14.05.19 15:47, Ingo wrote:
> Could it be possible that the operating system does this even before it gets 
> to the comport object?

well, those flags are supposed to control exactly what "the operating
system does" in this respect.

fgmasdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Ingo]

Could it be possible that the operating system does this even before it gets 
to the comport object?




From: Pd-list [mailto:pd-list-boun...@lists.iem.at] On Behalf Of Martin Peach
Sent: Tuesday, May 14, 2019 3:32 PM
To: pd-list@lists.iem.at
Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10

It's odd that the lines
/* no post processing */
new->c_oflag &= ~OPOST;

and
/* always nocanonical, this means raw i/o no terminal */
new->c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);

_are_ present in open_serial() in comport.c.
That should disable all postprocessing of traffic.
Martin

On Tue, May 14, 2019 at 7:58 AM Roman Haefeli  wrote:
On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
> > > 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?

Yeah, I will when I have access to an Arduino (or other serial device)
and report back. Thanks for looking into this.

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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Christof Ressi]

> That should disable all postprocessing of traffic.

I think the problem is input processing, look at the flags set by cfmakeraw 
(http://man7.org/linux/man-pages/man3/tcflow.3.html), they explicitly disable 
CR/NL transformation:

termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP
   | INLCR | IGNCR | ICRNL | IXON);

I don't know what's the default value for c_iflag, but I suppose it's platform 
specific. maybe [comport] could just do cfmakeraw(), to make sure it is really 
in raw mode.

Christof

Gesendet: Dienstag, 14. Mai 2019 um 15:32 Uhr
Von: "Martin Peach" 
An: "pd-list@lists.iem.at" 
Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10

It's odd that the lines
 

/* no post processing */
new->c_oflag &= ~OPOST;
 and
 

/* always nocanonical, this means raw i/o no terminal */
new->c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);

_are_ present in open_serial() in comport.c.That should disable all 
postprocessing of traffic.
Martin 

On Tue, May 14, 2019 at 7:58 AM Roman Haefeli 
mailto:reduz...@gmail.com]> wrote:On Tue, 2019-05-14 at 
13:27 +0200, Christof Ressi wrote:
> > > 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?

Yeah, I will when I have access to an Arduino (or other serial device)
and report back. Thanks for looking into this.

Roman
___
Pd-list@lists.iem.at[mailto:Pd-list@lists.iem.at] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[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[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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Martin Peach]

It's odd that the lines

/* no post processing */
new->c_oflag &= ~OPOST;

and

/* always nocanonical, this means raw i/o no terminal */
new->c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG);
_are_ present in open_serial() in comport.c.
That should disable all postprocessing of traffic.

Martin

On Tue, May 14, 2019 at 7:58 AM Roman Haefeli  wrote:

> On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
> > > > 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?
>
> Yeah, I will when I have access to an Arduino (or other serial device)
> and report back. Thanks for looking into this.
>
> 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

Re: [PD] Shared buffer between multiple instances of PD

[Sebastian Lexer]

Thank you!
S

IOhannes m zmoelnig wrote on 14/05/2019 13:35:

On 14.05.19 14:18, Sebastian Lexer wrote:

Hi,

I am wondering whether it is (at least theoretically) possible to create
an array/buffer that is accessed from two instances of PD on the same
computer.
One of these instances would write/read from this buffer, the second
would be read only.

If possible, would you have any pointers how to realise this?


search deken for "shmem".

fgasmdr
IOhannes



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list


--
Sent from Postbox 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Shared buffer between multiple instances of PD

[IOhannes m zmoelnig]

On 14.05.19 14:18, Sebastian Lexer wrote:
> Hi,
> 
> I am wondering whether it is (at least theoretically) possible to create
> an array/buffer that is accessed from two instances of PD on the same
> computer.
> One of these instances would write/read from this buffer, the second
> would be read only.
> 
> If possible, would you have any pointers how to realise this?


search deken for "shmem".

fgasmdr
IOhannes



signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

[PD] Shared buffer between multiple instances of PD

[Sebastian Lexer]

Hi,

I am wondering whether it is (at least theoretically) possible to create 
an array/buffer that is accessed from two instances of PD on the same 
computer.
One of these instances would write/read from this buffer, the second 
would be read only.


If possible, would you have any pointers how to realise this?

Thanks,
Sebastian



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Roman Haefeli]

On Tue, 2019-05-14 at 13:27 +0200, Christof Ressi wrote:
> > > 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?

Yeah, I will when I have access to an Arduino (or other serial device)
and report back. Thanks for looking into this.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Ingo]

This works:

$ sudo stty -F /dev/ttyACM0 raw

https://acassis.wordpress.com/2016/01/22/configuring-linuxs-serial-port-to-raw-mode/

Now I need to find a way to set it permanently to raw.
I think the [comport] object should actually do this during initilization. 
There is no need for modem options in Pd.

Thanks, Roman for finding the cause!

Ingo


> -Original Message-
> From: Pd-list [mailto:pd-list-boun...@lists.iem.at] On Behalf Of Roman
> Haefeli
> Sent: Tuesday, May 14, 2019 12:58 PM
> To: pd-list@lists.iem.at
> Subject: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
>
> Does that help:
>
> https://superuser.com/questions/714078/wrong-newline-character-over-
> serial-port-cr-instead-of-lf
>
> Roman
>
> On Tue, 2019-05-14 at 12:35 +0200, Ingo wrote:
> > Sorry, this was meant to be:
> > Carriage Return is 13. Line Feed is 10 (not 0x10).
> >
> > > -Original Message-
> > > From: Pd-list [mailto:pd-list-boun...@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-boun...@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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Christof Ressi]

> > 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" 
> An: 'Ingo' , "'Roman Haefeli'" , 
> adr...@gmail.com, itensi...@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:i...@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-boun...@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-boun...@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?

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Ingo]

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:i...@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-boun...@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-boun...@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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Christof Ressi]

or just use cfmakeraw? http://man7.org/linux/man-pages/man3/tcflow.3.html

> Gesendet: Dienstag, 14. Mai 2019 um 13:01 Uhr
> Von: "Christof Ressi" 
> An: Ingo 
> Cc: pd-list@lists.iem.at
> Betreff: Re: [PD] Comport problem with Arduino: 13 is coming in as 10
>
> I skimmed through the comport code and it certainly doesn't translate 
> anything but I stumbled across this:
> https://stackoverflow.com/a/42218147/6063908
> or look for INLCR in http://man7.org/linux/man-pages/man3/tcflow.3.html
>
> this only seems to affect [comport] on non-Windows platforms.
>
> you can try to add
>
> new->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | 
> IXON);
>
> after https://git.iem.at/pd/comport/blob/master/comport.c#L953 and recompile. 
> if that works we should probably make a PR and fix this.
>
> Christof
>
>
> > Gesendet: Dienstag, 14. Mai 2019 um 12:30 Uhr
> > Von: "Ingo" 
> > An: "'Roman Haefeli'" , pd-list@lists.iem.at
> > Betreff: 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-boun...@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
>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Christof Ressi]

I skimmed through the comport code and it certainly doesn't translate anything 
but I stumbled across this:
https://stackoverflow.com/a/42218147/6063908
or look for INLCR in http://man7.org/linux/man-pages/man3/tcflow.3.html

this only seems to affect [comport] on non-Windows platforms.

you can try to add

new->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | 
IXON);

after https://git.iem.at/pd/comport/blob/master/comport.c#L953 and recompile. 
if that works we should probably make a PR and fix this.

Christof


> Gesendet: Dienstag, 14. Mai 2019 um 12:30 Uhr
> Von: "Ingo" 
> An: "'Roman Haefeli'" , pd-list@lists.iem.at
> Betreff: 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-boun...@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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Roman Haefeli]

Does that help:

https://superuser.com/questions/714078/wrong-newline-character-over-serial-port-cr-instead-of-lf

Roman

On Tue, 2019-05-14 at 12:35 +0200, Ingo wrote:
> Sorry, this was meant to be:
> Carriage Return is 13. Line Feed is 10 (not 0x10).
> 
> > -Original Message-
> > From: Pd-list [mailto:pd-list-boun...@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-boun...@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
> 
> 


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Alexandros]

On 14/5/19 10:08 π.μ., Simon Iten wrote:
> i think it boiled down to using Serial.write with an explicit byte statement 
>
> Serial.write(byte(variable));
>
> at least this works with all my midi gear here. what happens if you send 10 
> from the arduino? do you also get a 10 in pd?
Doesn't work here, still get 10 instead of 13.



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Ingo]

Sorry, this was meant to be:
Carriage Return is 13. Line Feed is 10 (not 0x10).

> -Original Message-
> From: Pd-list [mailto:pd-list-boun...@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-boun...@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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Ingo]

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-boun...@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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Roman Haefeli]

On Tue, 2019-05-14 at 10:00 +0100, Alexandros wrote:
> On 14/5/19 9:45 π.μ., 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


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Simon Iten]

i think it boiled down to using Serial.write with an explicit byte statement 

Serial.write(byte(variable));

at least this works with all my midi gear here. what happens if you send 10 
from the arduino? do you also get a 10 in pd?

> On 14 May 2019, at 10:45, 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.
> 
> 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

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Alexandros]

On 14/5/19 9:45 π.μ., 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. Martin Peach replied by saying that
he couldn't reproduce it and that [comport] doesn't interpret anything,
so it shouldn't be a problem with the object, but I would leave that to
him again, or anyone else who can give a definite answer.

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().





___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] Comport problem with Arduino: 13 is coming in as 10

[Roman Haefeli]

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.

Roman


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list