Thanks Karl and Soeren. This helps a lot since the next parts I am working on is updating the MIDI PD to handle the more complicated parts of the MIDI protocol. These include the following: SysReal packets interrupting regular packets, "running status" packets that omit the status byte, SysEx packets terminated by non-EOX status bytes, and plain old identifying and getting past garbage data.
-Chris ---------------------------------------- > Date: Tue, 6 Sep 2016 06:01:42 -0400 > From: [email protected] > To: [email protected] > CC: [email protected]; [email protected] > Subject: Re: [sigrok-devel] Recommendations for displaying of overlapping > packets > > Hi Chris, > > I also agree that option 4 is best. Not just for purely visual > reasons, though: it is also that scripts using the sigrok-cli > output can make sense of the data. If "regular" MIDI packets > are interrupted also in the textual output, such scripts would > need to re-assemble the textual MIDI packet output to evaluate > them. > When using a different annotation class for the interrupting > packets, textual processing of the data suddenly becomes a > lot easier. > > Regards, > -Soeren > > On 2016-09-06 05:46, Karl Palsson wrote: >> Chris Dreher <[email protected]> wrote: >>> I am looking for some advice on the best option to display >>> overlapping packet decodes. See attached mock-up images. >>> >>> In MIDI, System Realtime packets are allowed to briefly >>> interrupt the byte stream of other packets. When the System >>> Realtime packet is done, the previously interrupted packet >>> continues. Because of this there are several options for >>> displaying packets. >>> >>> Here are some of the options (see attached mock-up images): >>> Option 1: let the packets overlaps in the GUI. It's messy >>> looking. Option 2: give the System Realtime packets a different >>> color. Better but messy. Option 3: show the incomplete parts of >>> a packet with a '...' and don't decode it until the end. Option >>> 4: put the System Realtime packets on a different line. >>> >>> Currently, I lean towards Option 4. I know how to code the >>> above options. Are there other options? >> >> Option 4 looks the best to me as well. >> >> Cheers, >> Karl P >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> sigrok-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/sigrok-devel ------------------------------------------------------------------------------ _______________________________________________ sigrok-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sigrok-devel
