[sdiy] MIDI control syntax to debug 16 bits values on the MIDI steam using MIDI-OX MIDI monitor ?

[brianw]

Yes, you make a very good point. When debugging MIDI streams, it's best to have a precise picture of the data on the wire.

USB-MIDI makes this impossible, because the USB data always has the MIDI Status Byte added to the MIDI bytes, plus it has redundant status bits (4 of them) in the 4th byte of the USB Packet Header that describes the message. Heaven help you if the Code Index Number does not match the required Status Byte. Yes, I've actually seen open-source USB-MIDI firmware that somehow managed to allow this redundant data to diverge.

However, with something like the PIC processor, where the raw UART data is accessible, it would be possible to dump this on a debug port, perhaps via serial RS232 or similar. I have also had success with custom USB Device firmware by adding an extra debug Endpoint over USB, where I can define my own custom packets for debugging information. With my most complex USB Device firmware, I write a USB protocol to query any internal variable in the firmware so I can display it on the USB Host computer. I'm sure it would be possible to create an Interrupt Endpoint with just the raw MIDI data.

Of course, if you have an oscilloscope that can decode serial UART frames, that might be easier.

Also, if you have a spare PIC evaluation board and the proper electronic for MIDI In and MIDI Thru, it should be possible to design and build a custom MIDI debugging device. It could be inserted between any two pieces of MIDI hardware. The MIDI Thru would have zero-latency pass-through, so as not to affect the original data. The MIDI In would allow the PIC firmware (or whatever processor you choose) to display or translate the raw MIDI data for diagnostics.

I got my start in MIDI before USB-MIDI came out, so Running Status versus an explicit Status Byte was always obvious. Once USB-MIDI became prevalent, low-level debugging has become a little more difficult.

Brian


On Jan 11, 2025, at 6:53 PM, chris wrote:
> Apart from what has been said about MIDI never being able to transport
> full 8 bit bytes directly, there is one thing to have in mind with a
> MidiOx monitor.
> 
> When receiving just data bytes (hi bit of 0), the receiving MIDI driver
> applies running status, and in turn you see expanded full messages in
> MidiOx even though there wasn't a status byte on the cable.
> 
> I just experienced this last month debugging a wonky sender. Using an
> oscilloscope on the cable (well, after the opto coupler...) revealed
> what was really transferred physically.
> 
> Chris
> 
> 
> 
> On Sat, 11 Jan 2025 16:49:26 -0500 Jean-Pierre Desrochers wrote:
>> I’m debugging a PIC program that normally sends MIDI data on one of the micro’s UART port.
>> 
>> And that works fine.
>> 
>> But I’m in a debugging section where I’d like to use this MIDI output port
>> to output 16 bits datas  (2 consecutives bytes) wired on my Windows MIDI-OX MIDI stream monitor.
>> The thing is that this program check the incoming MIDI command data values
>> and do not show those that would exceed standard MIDI specs..
>> 
>> So my question is :
>> 
>> Is there a MIDI command (SYSEX or whatever..) that I could put 2 consecutive 8 bits datas in
>> and would be accepted in the standard MIDI protocol ??
>> 
>> 
>> 
>> For example Control Change (0xE0) uses 2 consecutive bytes variables but each of them
>> cannot exceed 0x7F. So.. not usable for me.
>> 
>> 
>> 
>> Any commands that would do ?
>> 
>> Thanks.