Re: [PD] Question about transmission order to serial port [comport] with two independent streams
The SLIP protocol has actually more overhead than what I'm thinking of.
generally the overhead is one byte per message + escape bytes if the data itself contains 192 or 219.
On top of it it is more prone to generate errors with MIDI since it uses Bytes
if used correctly, the SLIP protocol can handle any kind of data (otherwise it would be not a very useful protocol).
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
message passing in Pd is synchronous, so there's no way two messages can interleave.
still you need to think about how to reliably distinguish MIDI from other data in your Arduino, so the advice in my last mail might still apply.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 15:58 Uhr Von: "Ingo Scherzinger" eeemail@dynasample.com An: "'Christof Ressi'" christof.ressi@gmx.at, 'Pd-List' pd-list@lists.iem.at Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
Thanks, Christof!
The SLIP protocol has actually more overhead than what I'm thinking of. On top of it it is more prone to generate errors with MIDI since it uses Bytes that are also used as MIDI Status Bytes.
My question is actually very simple:
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
Ingo
-----Original Message----- From: Christof Ressi [mailto:christof.ressi@gmx.at] Sent: Sunday, July 14, 2019 3:32 PM To: Ingo; Pd-List Subject: Aw: [PD] Question about transmission order to serial port [comport] with two independent streams
When sending data over a serial connection, it's good to have some sort of protocol to distinguish messages. A very common protocol is SLIP https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol It's often used for streaming OSC messages (e.g. TCP or serial). You can encode in Pd with [mrpeach/slipenc] and decode on the Arduino with https://github.com/CNMAT/OSC/blob/master/SLIPEncodedSerial.h
On the other hand, MIDI is already a protocol (messages are delimited by status bytes) and you could send your display data on an unused MIDI channel or even as Sysex messages.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 14:59 Uhr Von: "Ingo" ingo@miamiwave.com An: 'pd-list' pd-list@iem.at Betreff: [PD] Question about transmission order to serial port [comport] with two independent streams
Hi there,
I need to send both display data and MIDI out data to the same serial port via USB using [comport] going to an Arduino Micro. The MIDI goes on to the serial transmit pin and the display goes to the I2C pins. Unfortunately neither the display nor the MIDI data is very predictable concerning timing.
The display uses drip to send one character after the other and MIDI is sending out manipulated data from the MIDI input whenever MIDI
comes in.
Both senders are on different sections of the software and are not synchronized in any way.
Since I need to find a way to split up each stream inside of the Arduino without meshing them up and causing errors my question is:
Does Pd send one message (or packed numbers) with two or more values without interruption? If yes I could simply prepend an unused number (like e.g. 253 or 254) as a header in front of each MIDI Byte. If needed another one for the display data. (The latter is probably not necessary since I can reset after each MIDI Byte inside of the Arduino to keep sending again to the display.)
Meshing up MIDI and display data would be absolutely chaotic! If I can't guarantee that each Byte goes to the correct destination I will have to use two separate arduinos.
Thanks! Ingo
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I actually only need one byte in front of each MIDI byte. After the actual value the Arduino resets itself. This insures that only MIDI needs one extra byte and nothing else. That is the lowest overhead you can probably get in terms of transmissin and fastest MIDI timing.
message passing in Pd is synchronous, so there's no way two messages can interleave.
This answers my question! Thanks, Christof! In this case it should work the way I have it in mind.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Christof Ressi Sent: Sunday, July 14, 2019 4:24 PM To: ingo@dynasample.com; Pd-List Subject: Re: [PD] Question about transmission order to serial port [comport] with two independent streams
The SLIP protocol has actually more overhead than what I'm thinking of.
generally the overhead is one byte per message + escape bytes if the data itself contains 192 or 219.
On top of it it is more prone to generate errors with MIDI since it uses Bytes
if used correctly, the SLIP protocol can handle any kind of data (otherwise it would be not a very useful protocol).
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
message passing in Pd is synchronous, so there's no way two messages can interleave.
still you need to think about how to reliably distinguish MIDI from other data in your Arduino, so the advice in my last mail might still apply.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 15:58 Uhr Von: "Ingo Scherzinger" eeemail@dynasample.com An: "'Christof Ressi'" christof.ressi@gmx.at, 'Pd-List' pd-list@lists.iem.at Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
Thanks, Christof!
The SLIP protocol has actually more overhead than what I'm thinking of. On top of it it is more prone to generate errors with MIDI since it uses Bytes that are also used as MIDI Status Bytes.
My question is actually very simple:
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
Ingo
-----Original Message----- From: Christof Ressi [mailto:christof.ressi@gmx.at] Sent: Sunday, July 14, 2019 3:32 PM To: Ingo; Pd-List Subject: Aw: [PD] Question about transmission order to serial port [comport] with two independent streams
When sending data over a serial connection, it's good to have some sort of protocol to distinguish messages. A very common protocol is SLIP https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol It's often used for streaming OSC messages (e.g. TCP or serial). You can encode in Pd with [mrpeach/slipenc] and decode on the Arduino with https://github.com/CNMAT/OSC/blob/master/SLIPEncodedSerial.h
On the other hand, MIDI is already a protocol (messages are delimited by status bytes) and you could send your display data on an unused MIDI channel or even as Sysex messages.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 14:59 Uhr Von: "Ingo" ingo@miamiwave.com An: 'pd-list' pd-list@iem.at Betreff: [PD] Question about transmission order to serial port [comport] with two independent streams
Hi there,
I need to send both display data and MIDI out data to the same serial port via USB using [comport] going to an Arduino Micro. The MIDI goes on to the serial transmit pin and the display goes to the I2C pins. Unfortunately neither the display nor the MIDI data is very predictable concerning timing.
The display uses drip to send one character after the other and MIDI is sending out manipulated data from the MIDI input whenever MIDI
comes in.
Both senders are on different sections of the software and are not synchronized in any way.
Since I need to find a way to split up each stream inside of the Arduino without meshing them up and causing errors my question is:
Does Pd send one message (or packed numbers) with two or more values without interruption? If yes I could simply prepend an unused number (like e.g. 253 or 254) as a header in front of each MIDI Byte. If needed another one for the display data. (The latter is probably not necessary since I can reset after each MIDI Byte inside of the Arduino to keep sending again to the display.)
Meshing up MIDI and display data would be absolutely chaotic! If I can't guarantee that each Byte goes to the correct destination I will have to use two separate arduinos.
Thanks! Ingo
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
That is the lowest overhead you can probably get in terms of transmissin and fastest MIDI timing.
I don't know what your "display" data looks like, but as I wrote, MIDI is already a protocol, so you can simply take an unused status byte (e.g. 240 = Sysex start) for transmitting your non-MIDI data:
240, <numbytes>, <data0>, <data1>, <data2>, etc.
This would be quite efficient and also easy to parse.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 16:33 Uhr Von: "Ingo" ingo@miamiwave.com An: "'Christof Ressi'" christof.ressi@gmx.at, ingo@dynasample.com, 'Pd-List' pd-list@lists.iem.at Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
I actually only need one byte in front of each MIDI byte. After the actual value the Arduino resets itself. This insures that only MIDI needs one extra byte and nothing else. That is the lowest overhead you can probably get in terms of transmissin and fastest MIDI timing.
message passing in Pd is synchronous, so there's no way two messages can interleave.
This answers my question! Thanks, Christof! In this case it should work the way I have it in mind.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Christof Ressi Sent: Sunday, July 14, 2019 4:24 PM To: ingo@dynasample.com; Pd-List Subject: Re: [PD] Question about transmission order to serial port [comport] with two independent streams
The SLIP protocol has actually more overhead than what I'm thinking of.
generally the overhead is one byte per message + escape bytes if the data itself contains 192 or 219.
On top of it it is more prone to generate errors with MIDI since it uses Bytes
if used correctly, the SLIP protocol can handle any kind of data (otherwise it would be not a very useful protocol).
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
message passing in Pd is synchronous, so there's no way two messages can interleave.
still you need to think about how to reliably distinguish MIDI from other data in your Arduino, so the advice in my last mail might still apply.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 15:58 Uhr Von: "Ingo Scherzinger" eeemail@dynasample.com An: "'Christof Ressi'" christof.ressi@gmx.at, 'Pd-List' pd-list@lists.iem.at Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
Thanks, Christof!
The SLIP protocol has actually more overhead than what I'm thinking of. On top of it it is more prone to generate errors with MIDI since it uses Bytes that are also used as MIDI Status Bytes.
My question is actually very simple:
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
Ingo
-----Original Message----- From: Christof Ressi [mailto:christof.ressi@gmx.at] Sent: Sunday, July 14, 2019 3:32 PM To: Ingo; Pd-List Subject: Aw: [PD] Question about transmission order to serial port [comport] with two independent streams
When sending data over a serial connection, it's good to have some sort of protocol to distinguish messages. A very common protocol is SLIP https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol It's often used for streaming OSC messages (e.g. TCP or serial). You can encode in Pd with [mrpeach/slipenc] and decode on the Arduino with https://github.com/CNMAT/OSC/blob/master/SLIPEncodedSerial.h
On the other hand, MIDI is already a protocol (messages are delimited by status bytes) and you could send your display data on an unused MIDI channel or even as Sysex messages.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 14:59 Uhr Von: "Ingo" ingo@miamiwave.com An: 'pd-list' pd-list@iem.at Betreff: [PD] Question about transmission order to serial port [comport] with two independent streams
Hi there,
I need to send both display data and MIDI out data to the same serial port via USB using [comport] going to an Arduino Micro. The MIDI goes on to the serial transmit pin and the display goes to the I2C pins. Unfortunately neither the display nor the MIDI data is very predictable concerning timing.
The display uses drip to send one character after the other and MIDI is sending out manipulated data from the MIDI input whenever MIDI
comes in.
Both senders are on different sections of the software and are not synchronized in any way.
Since I need to find a way to split up each stream inside of the Arduino without meshing them up and causing errors my question is:
Does Pd send one message (or packed numbers) with two or more values without interruption? If yes I could simply prepend an unused number (like e.g. 253 or 254) as a header in front of each MIDI Byte. If needed another one for the display data. (The latter is probably not necessary since I can reset after each MIDI Byte inside of the Arduino to keep sending again to the display.)
Meshing up MIDI and display data would be absolutely chaotic! If I can't guarantee that each Byte goes to the correct destination I will have to use two separate arduinos.
Thanks! Ingo
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
This would work but require that I change tha way I send my display data. Right now I send the command for the line number and first column followed by the 20 characters for the entire line.
Using a status byte for the display instead of MIDI would require sending all display characters before going back to MIDI or sending the line and column number anew for resuming with the display.
Using a unused status byte like 253 (that is one of the 3 bytes that are not used at all for MIDI) for each MIDI byte let's me interrupt the display and return to it without any new display header information. Hence the MIDI timing will most likely be more precise. As I had mentioned - I don't want to wait with MIDI for the display to finish as MIDI is timing critical while the display isn't.
Ingo
-----Original Message----- From: Christof Ressi [mailto:christof.ressi@gmx.at] Sent: Sunday, July 14, 2019 4:52 PM To: Ingo; Pd-List Subject: Aw: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
That is the lowest overhead you can probably get in terms of transmissin and fastest MIDI timing.
I don't know what your "display" data looks like, but as I wrote, MIDI is already a protocol, so you can simply take an unused status byte (e.g. 240 = Sysex start) for transmitting your non-MIDI data:
240, <numbytes>, <data0>, <data1>, <data2>, etc.
This would be quite efficient and also easy to parse.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 16:33 Uhr Von: "Ingo" ingo@miamiwave.com An: "'Christof Ressi'" christof.ressi@gmx.at, ingo@dynasample.com, 'Pd-List' pd-list@lists.iem.at Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
I actually only need one byte in front of each MIDI byte. After the actual value the Arduino resets itself. This insures that only MIDI needs one extra byte and nothing else. That is the lowest overhead you can probably get in terms of transmissin and fastest MIDI timing.
message passing in Pd is synchronous, so there's no way two messages can interleave.
This answers my question! Thanks, Christof! In this case it should work the way I have it in mind.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Christof Ressi Sent: Sunday, July 14, 2019 4:24 PM To: ingo@dynasample.com; Pd-List Subject: Re: [PD] Question about transmission order to serial port [comport] with two independent streams
The SLIP protocol has actually more overhead than what I'm thinking of.
generally the overhead is one byte per message + escape bytes if the data itself contains 192 or 219.
On top of it it is more prone to generate errors with MIDI since it uses Bytes
if used correctly, the SLIP protocol can handle any kind of data (otherwise it would be not a very useful protocol).
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
message passing in Pd is synchronous, so there's no way two messages can interleave.
still you need to think about how to reliably distinguish MIDI from other data in your Arduino, so the advice in my last mail might still apply.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 15:58 Uhr Von: "Ingo Scherzinger" eeemail@dynasample.com An: "'Christof Ressi'" christof.ressi@gmx.at, 'Pd-List' pd-list@lists.iem.at Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
Thanks, Christof!
The SLIP protocol has actually more overhead than what I'm thinking of. On top of it it is more prone to generate errors with MIDI since it uses Bytes that are also used as MIDI Status Bytes.
My question is actually very simple:
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
Ingo
-----Original Message----- From: Christof Ressi [mailto:christof.ressi@gmx.at] Sent: Sunday, July 14, 2019 3:32 PM To: Ingo; Pd-List Subject: Aw: [PD] Question about transmission order to serial port [comport] with two independent streams
When sending data over a serial connection, it's good to have some sort of protocol to distinguish messages. A very common protocol is SLIP https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol It's often used for streaming OSC messages (e.g. TCP or serial). You can encode in Pd with [mrpeach/slipenc] and decode on the Arduino with https://github.com/CNMAT/OSC/blob/master/SLIPEncodedSerial.h
On the other hand, MIDI is already a protocol (messages are delimited by status bytes) and you could send your display data on an unused MIDI channel or even as Sysex messages.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 14:59 Uhr Von: "Ingo" ingo@miamiwave.com An: 'pd-list' pd-list@iem.at Betreff: [PD] Question about transmission order to serial port [comport] with two independent streams
Hi there,
I need to send both display data and MIDI out data to the same serial port via USB using [comport] going to an Arduino Micro. The MIDI goes on to the serial transmit pin and the display goes to the I2C pins. Unfortunately neither the display nor the MIDI data is very predictable concerning timing.
The display uses drip to send one character after the other and MIDI is sending out manipulated data from the MIDI input whenever MIDI
comes in.
Both senders are on different sections of the software and are not synchronized in any way.
Since I need to find a way to split up each stream inside of the Arduino without meshing them up and causing errors my
question is:
Does Pd send one message (or packed numbers) with two or more values without interruption? If yes I could simply prepend an unused number (like e.g. 253 or 254) as a header in front of each MIDI Byte. If needed another one for the display data. (The latter is probably not necessary since I can reset after each MIDI Byte inside of the Arduino to keep sending again to the display.)
Meshing up MIDI and display data would be absolutely chaotic! If I can't guarantee that each Byte goes to the correct destination I will have to use two separate arduinos.
Thanks! Ingo
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
I see! This makes sense.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 18:15 Uhr Von: "Ingo" ingo@miamiwave.com An: "'Christof Ressi'" christof.ressi@gmx.at, 'Pd-List' pd-list@lists.iem.at Betreff: RE: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
This would work but require that I change tha way I send my display data. Right now I send the command for the line number and first column followed by the 20 characters for the entire line.
Using a status byte for the display instead of MIDI would require sending all display characters before going back to MIDI or sending the line and column number anew for resuming with the display.
Using a unused status byte like 253 (that is one of the 3 bytes that are not used at all for MIDI) for each MIDI byte let's me interrupt the display and return to it without any new display header information. Hence the MIDI timing will most likely be more precise. As I had mentioned - I don't want to wait with MIDI for the display to finish as MIDI is timing critical while the display isn't.
Ingo
-----Original Message----- From: Christof Ressi [mailto:christof.ressi@gmx.at] Sent: Sunday, July 14, 2019 4:52 PM To: Ingo; Pd-List Subject: Aw: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
That is the lowest overhead you can probably get in terms of transmissin and fastest MIDI timing.
I don't know what your "display" data looks like, but as I wrote, MIDI is already a protocol, so you can simply take an unused status byte (e.g. 240 = Sysex start) for transmitting your non-MIDI data:
240, <numbytes>, <data0>, <data1>, <data2>, etc.
This would be quite efficient and also easy to parse.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 16:33 Uhr Von: "Ingo" ingo@miamiwave.com An: "'Christof Ressi'" christof.ressi@gmx.at, ingo@dynasample.com, 'Pd-List' pd-list@lists.iem.at Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
I actually only need one byte in front of each MIDI byte. After the actual value the Arduino resets itself. This insures that only MIDI needs one extra byte and nothing else. That is the lowest overhead you can probably get in terms of transmissin and fastest MIDI timing.
message passing in Pd is synchronous, so there's no way two messages can interleave.
This answers my question! Thanks, Christof! In this case it should work the way I have it in mind.
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of Christof Ressi Sent: Sunday, July 14, 2019 4:24 PM To: ingo@dynasample.com; Pd-List Subject: Re: [PD] Question about transmission order to serial port [comport] with two independent streams
The SLIP protocol has actually more overhead than what I'm thinking of.
generally the overhead is one byte per message + escape bytes if the data itself contains 192 or 219.
On top of it it is more prone to generate errors with MIDI since it uses Bytes
if used correctly, the SLIP protocol can handle any kind of data (otherwise it would be not a very useful protocol).
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
message passing in Pd is synchronous, so there's no way two messages can interleave.
still you need to think about how to reliably distinguish MIDI from other data in your Arduino, so the advice in my last mail might still apply.
Christof
Gesendet: Sonntag, 14. Juli 2019 um 15:58 Uhr Von: "Ingo Scherzinger" eeemail@dynasample.com An: "'Christof Ressi'" christof.ressi@gmx.at, 'Pd-List' pd-list@lists.iem.at Betreff: RE: [PD] Question about transmission order to serial port [comport] with two independent streams
Thanks, Christof!
The SLIP protocol has actually more overhead than what I'm thinking of. On top of it it is more prone to generate errors with MIDI since it uses Bytes that are also used as MIDI Status Bytes.
My question is actually very simple:
Can a message going to comport be interrupted by another message that is being sent to [comport] almost at the same time or will one message or packed list always be processed completely before anything else will be sent to the same [comport] object.
Ingo
-----Original Message----- From: Christof Ressi [mailto:christof.ressi@gmx.at] Sent: Sunday, July 14, 2019 3:32 PM To: Ingo; Pd-List Subject: Aw: [PD] Question about transmission order to serial port [comport] with two independent streams
When sending data over a serial connection, it's good to have some sort of protocol to distinguish messages. A very common protocol is SLIP https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol It's often used for streaming OSC messages (e.g. TCP or serial). You can encode in Pd with [mrpeach/slipenc] and decode on the Arduino with https://github.com/CNMAT/OSC/blob/master/SLIPEncodedSerial.h
On the other hand, MIDI is already a protocol (messages are delimited by status bytes) and you could send your display data on an unused MIDI channel or even as Sysex messages.
Christof
> Gesendet: Sonntag, 14. Juli 2019 um 14:59 Uhr > Von: "Ingo" ingo@miamiwave.com > An: 'pd-list' pd-list@iem.at > Betreff: [PD] Question about transmission order to serial port > [comport] with two independent streams > > Hi there, > > I need to send both display data and MIDI out data to the same > serial port via USB using [comport] going to an Arduino Micro. > The MIDI goes on to the serial transmit pin and the display > goes to the I2C pins. > Unfortunately neither the display nor the MIDI data is very > predictable concerning timing. > > The display uses drip to send one character after the other > and MIDI is sending out manipulated data from the MIDI input > whenever MIDI comes in. > Both senders are on different sections of the software and are > not synchronized in any way. > > Since I need to find a way to split up each stream inside of > the Arduino without meshing them up and causing errors my
question is:
> > Does Pd send one message (or packed numbers) with two or more > values without interruption? > If yes I could simply prepend an unused number (like e.g. 253 > or > 254) as a header in front of each MIDI Byte. > If needed another one for the display data. > (The latter is probably not necessary since I can reset after > each MIDI Byte inside of the Arduino to keep sending again to > the > display.) > > Meshing up MIDI and display data would be absolutely chaotic! > If I can't guarantee that each Byte goes to the correct > destination I will have to use two separate arduinos. > > Thanks! > Ingo > > > > > > _______________________________________________ > 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
Am 14. Juli 2019 16:23:39 MESZ schrieb Christof Ressi christof.ressi@gmx.at:
Can a message going to comport be interrupted by another message that
is being
sent to [comport] almost at the same time or will one message or
packed list
always be processed completely before anything else will be sent to
the same
[comport] object.
message passing in Pd is synchronous, so there's no way two messages can interleave.
unless, of course, you are breaking stack-based processing by use of [delay] or ... [drip] (in scheduled mode).
mfg.hdf.of IOhannes
I actually do use drip but only on the stream going to the display which should be interuptable. Not on the MIDI part that shouldn't be interrupted. So it should work the way that I have it in mind.
Thanks for the confirmation, IOhannes!
Ingo
-----Original Message----- From: Pd-list [mailto:pd-list-bounces@lists.iem.at] On Behalf Of IOhannes m zmölnig Sent: Monday, July 15, 2019 5:26 AM To: Pd-List Subject: Re: [PD] Question about transmission order to serial port [comport] with two independent streams
Am 14. Juli 2019 16:23:39 MESZ schrieb Christof Ressi christof.ressi@gmx.at:
Can a message going to comport be interrupted by another message that
is being
sent to [comport] almost at the same time or will one message or
packed list
always be processed completely before anything else will be sent to
the same
[comport] object.
message passing in Pd is synchronous, so there's no way two messages can interleave.
unless, of course, you are breaking stack-based processing by use of [delay] or ... [drip] (in scheduled mode).
mfg.hdf.of IOhannes
-- sent from my pdp-12
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
Ingo -
IOhannes m zmölnig