[PD] Question about transmission order to serial port [comport] with two independent streams

Ingo ingo at miamiwave.com
Sun Jul 14 18:15:46 CEST 2019


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 at 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 at miamiwave.com>
> > An: "'Christof Ressi'" <christof.ressi at gmx.at>, ingo at dynasample.com,
> > 'Pd-List' <pd-list at 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 at lists.iem.at] On Behalf Of
> > > Christof Ressi
> > > Sent: Sunday, July 14, 2019 4:24 PM
> > > To: ingo at 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 at dynasample.com>
> > > > An: "'Christof Ressi'" <christof.ressi at gmx.at>, 'Pd-List'
> > > > <pd-list at 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 at 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 at miamiwave.com>
> > > > > > An: 'pd-list' <pd-list at 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 at lists.iem.at mailing list UNSUBSCRIBE and
> > > > > > account-management ->
> > > > > > https://lists.puredata.info/listinfo/pd-list
> > > > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Pd-list at lists.iem.at mailing list
> > > UNSUBSCRIBE and account-management ->
> > > https://lists.puredata.info/listinfo/pd-list
> >
> >
> >







More information about the Pd-list mailing list