RG-16 with MOTU MIDI Express XT

M

metropit

Member
Hello,

I ran into an issue when using RG-16 with MOTU MIDI Express XT and MFC-101.

The setup is:

MFC-101 ----> MOTU MIDI Express XT ---> RG-16

It seems that CC message 92 was received on RG-16, while CC 88-91 works well.

I did a capture on MIDI message, and verified that CC message is sent from MOTU to RG-16.

However, if I connect RG-16 right after MFC-101, then it works well.

Any suggestion on how can I further isolate the problem? Since it is verified CC 92 is relayed by MOTU, but it seems RG-16 just ignored it due to some reason.

Any help is greatly appreciated!
 
It sounds like there's some kind of MIDI hardware issue. I suggest monitoring the MIDI Thru of the RG-16, and see if you can see the CC messages coming out of it successfully. Also, test CCs 93-95 as well.
 
Thanks a lot for the suggestion.

I reassigned the MIDI channel of the RG-16 to CH 2, and now the issue moved to CC 88 (Function Switch 1). And now CC 92 ~ 95 works well............

The attached screen cap is the MIDI Monitor output by monitoring RG-16 MIDI Thru.

Apparently CC 88 was sent to RG-16, but there's no action for Function Switch 1......weird.
 

Attachments

  • RG16-Thru.png
    RG16-Thru.png
    812.5 KB · Views: 3
BTW, I got a Amp Gizmo as well in CH3, and is connected after the MOTU MIDI Express XT as well similar to RG-16.
However, it works well without any problem.

Another finding is: if I send a standalone CC message 88 to RG-16, then it works well.
It seems the issue only occurs when there are multiple CC being sent to RG-16.
 
Last edited:
That's really odd. It sounds like the MIDI circuit is starting to act up. What's the serial number on the RG-16?
 
The SN is RG10376

The followings are the screen cap of the MIDI Monitor on the MIDI Thru port of RG-16.
Timestamps are in nanosecond format.

The "Direct-1" is the case MFC-101 ---> RG-16 directly.

There're 55 bytes sent in 33.078 ms

The "Thru-MOTU-1" is the case MFC-101 ---> MOTU ---> RG-16
And not only CC 88 doesn't work, CC 81 ~ 84 do not work either.
There're 55 bytes sent in 33.422 ms

MIDI standard stats 0.320 ms (320 us) per byte, which is 17.6 ms
It seems the overall timing is ok in both cases.

Will there be any way to see if RG-16 ignored some bytes due to timing error?

I think I'll try to hook up an oscilloscope later to check if there's any bit timing issue.
 

Attachments

  • Direct-1.png
    Direct-1.png
    41.2 KB · Views: 2
  • Thru-MOTU-1.png
    Thru-MOTU-1.png
    44.5 KB · Views: 2
Stranger and stranger... the data coming from the thru is ok. I have to suspect that the CPU is at fault.
 
Ok, here's the finding by attach a scope on MIDI Thru of RG-16.

WHITE(R3) line shows the captured signal WITHOUT MOTU between MFC-101 and RG-16
YELLOW(1) line shows the captured signal WITH MOTU between MFC-101 and RG-16


In the cap below, the signal between (a) and (b) (320us) on BOTH signal is a byte 0x58 (LSB first, b'0101 1000), which means 88
Byte1-57.png

And then, here's the value of CC 88 = 127 (0x7F, b'0111 1111)
Byte2-7F.png

In the cap below, the signal between (a) and (b) (320us) on WHITE is a byte 0xB1 (LSB first, b'1011 0001), which means CC to CH2,
Obviously, YELLOW signal didn't have the Status Byte B1 appear ahead of the Data Byte 88 and value 127.
Which means MOTU didn't meet the standard MIDI implementation.
Byte0-B1.png


Then the question left to answer is: WHY MIDI Monitor still can decode the MIDI message above for CC 88 ?

I guess the implementation in MIDI Monitor "ASSUME" the Data Bytes without Status Byte belong to the same Status Byte with previous MIDI message.............

Thanks RJM for your kindly help!! Cheers!
 
Last edited:
Aha!!! Excellent detective work!

The MOTU unit is using "Running Status" which is actually part of the MIDI standard but I think is a particularly bad idea. The idea is that you can omit the first byte of a MIDI message and it will reuse the first byte from the previous message. It cuts down on MIDI traffic, but it will also remove some of MIDI's error detection ability. When we created the RG-16, I didn't even know about running status, and once I did learn about it, I've never felt that I should update the RG-16 to include it. This is only the second device I've ever seen that uses running status.

I wonder if there's a setting in the MOTU to disable running status?
 
Thanks RJM for the detail explanation.
Had a lot of fun in discovering the issue and learning, indeed!

That explained why the same issue did not happen on Amp Gizmo since there's no continuous CC sent to CH3 for Amp Gizmo.
Unfortunately, there's no any setting which allows to disable Running Status on MOTU Express XT.

Will it be possible to grant a firmware version which supports Running Status for RG-16 (and Amp Gizmo)?

The reason to ask for this is that this kind of devices, such as MOTU, though they are mainly used for sequencer,
and indeed, by supporting Running Status can help to maintain low latency.
However, I do need this kind of device to connect multiple MIDI devices to minimize the latency.
 
Since the RG-16 has been discontinued for many years, it would be hard for me to justify the time required to do a firmware update. However, I will try to think of a solution for you.
 
rjmmusic said:
Since the RG-16 has been discontinued for many years, it would be hard for me to justify the time required to do a firmware update. However, I will try to think of a solution for you.
Click to expand...

Much appreciated!
BTW, soldering, firmware update or any electrical operation are NOT a problem for me.
Please feel free to let me know how to minimize the effort.
 
Hi RJM,

As told by the MOTU tech support, the Running Status can be disabled by enabling the "Direct Mode".
Let me give it a try to see if that solves the problem, will keep you posted later.
 
You must log in or register to reply here.
Back
Top