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:
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
> 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.
> Gese
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
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
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: Some
> 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
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 1
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 digita
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 c
> 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
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.
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/
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 on
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 t
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 oth
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 i
> > 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...@gm
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 sen
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 a
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 tr
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
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 h
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 proble
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
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
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 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
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 [c
29 matches
Mail list logo
