MIDI module missing random note-off events when using DIN-to-USB converter

Bug description:

When using a 5-pin DIN-to-USB MIDI converter, the MIDI module randomly misses note-off events, resulting in voices getting stuck on. I tried this using 3 different converters, a Moog Subsequent 37 (echo DIN to USB), an M-Audio UNO USB, and a cheap Victsing converter from Amazon that gets detected as “CH345”. All three behave the same. I previously used the M-Audio UNO with Linux (Ubuntu) with no issues, and all three devices are auto-detected by the SSP.

When using straight USB MIDI from my Moog Subsequent 37 or Akai LPK25, everything works as expected.

Steps to reproduce (use numbered list):

  1. Plug a USB-to-DIN converter into the USB MIDI port (any DIN MIDI source)
  2. Load the 8vwto preset and start playing note events, especially polyphonic notes.

MIDI modules quickly (for me) stop honoring note-off and get stuck with the MIDI gate reading high, even after a note-off was sent. I also created monophonic and 2 voice test patches, and the MIDI module(s) get stuck in new patches as well.

Software version:

Tested on 14092019 and 20012020.


Major (unable to use my main 61-key DIN keyboards)

1 Like

Have you looked at these threads?

I don’t have a 5-pin to USB convertor. Thus, I can’t try to replicate your issue. I’ll point this thread out to Bert.

Thanks for the links and visibility. I went through both of those during my initial setup and troubleshooting process. The one line from either doc that seemed relevant to this issue is:

The MIDI module remains busy until the note off occurs, so consecutive notes are assigned to the next available MIDI modules accepting that channel.

It seems that when a subsequent note-on event arrives on the same channel and is routed to another MIDI module, the “busy” module allocated previously doesn’t catch note-off events until its next cycle in the round-robin. Even when playing 8 notes, I often can’t get all modules to deactivate, as if the voices stuck on are then excluded from the RR cycle.

Due to my poor timing and/or fat-fingering, this also happens with monophonic voices when notes are played legato. It’s as if the subsequent note is assigned to a non-existent MIDI module until all notes are released and a new note-on then note-off is received by the only module present in the patch.

DIN sources tested:
Moog Subsequent 37
Moog Voyager XL
Casio CTK-601
Ableton Live MIDI track via ER-M Multiclock

If it helps, I can make a video.

I’ve sent a link and description to the man in charge. He’s a bit swamped this week but has read your symptom and will, hopefully, address it this week.

Hang tough!

There is a thread elsewhere in the forum about this legato issue and I’ll come up with a fix for this that makes both MPE and non MPE users happy.

But you write above that it works if you plug in a USB MIDI controller straight into the SSP:

From the SSP’s perspective there is no difference if you use a USB MIDI Controller and plug it straight in or plug in a USB-MIDI I/O box or cable.

I am not able to reproduce this using my Keystep. I send notes on one MIDI channel and I do not get any stuck notes.

  • There are other people in the forum using similar USB-MIDI cables who seem to have no problems. Can anyone reproduce your exact problem?

  • Is it possible one or more MIDI modules in the patch do not have the correct settings? Please see the software update posts @Kent mentioned that describe the note allocation logic of the midi module.

Again, the problem is in receiving MIDI note data translated from DIN to USB, not a problem with direct USB-MIDI sources. Using a Keystep with direct USB-MIDI will not recreate this issue. I will post a video illustrating the issue to make it easier to understand.

I don’t understand relying on other forum users to test this. A USB-MIDI adapter is a $30 part, and this functionality should be included in QA testing.

Here’s a quick and dirty video to better illustrate the behavior. There’s no audio output from the SSP in the video, just the visual of the gate signal. All MIDI data is coming in on a single channel (9). Apologies for the low audio level; I was just using the internal GoPro mic.

i checked both types and can confirm there are problems with both types
see my tread(s) about MIDI clock & MIDI cc

I’m using roland UM-one mk2 as DIN-to-USB MIDI converter.

[My setup]
Handsonic > Midi solutions event processor > UM one mk2 > SSP

I don’t have note-off issue at SSP untill now.
And I checked midi module’s gate by pressing C3 & E3 as you did.
I’m not too sure but I could not reproduce your problem on my setup.

great, what about MIDI clock ?(is the step sequencer slaved to MIDI clock without timing issues after >2 m)
and MIDI cc? (are you able to control e.g. WTO x/y/z position with a MIDI cc)

Thank you for trying this. Is your Event Processor passing the full MIDI stream or just certain messages to the SSP? Also can you tell me what the SSP shows when Roland UM-One is plugged in? Does it detect by device name or a generic name? The control module on the Roland looks almost identical to my Victsing, so I’m wondering if they’re the same chipset.

I suspect this could be an issue with Debian drivers for certain USB-MIDI converter chipsets. I will capture raw MIDI streams from all points in my device paths today to troubleshoot further.

I use Event processor to remap handsonic’s MIDI.
But if I don’t use Event Processor and connect handsonic to UM one directly, it’s also work.

It detect by device name, UM one.

TL;DR: It turns out ALL THREE of my adapters are the problem. I have ordered a Roland UM-One and will be trying that out next week.

I like to apply Occam’s Razor when troubleshooting. If I plug 3 previously-working devices into a new device, and something doesn’t work, I assume it’s a fault with the new device. I always try to troubleshoot extensively to rule out any outliers, but I was working on faulty assumptions here.

  1. The CH345 USB-MIDI chipset is AWFUL. It’s horribly written and mistranslates a lot. I threw that adapter away and suggest any other owners do the same.
  2. Older M-Audio Midisport Uno USB adapters have 1 erroneous instruction on the chipset, which just so happens to be very important for legato and polyphony. I found a 12 year-old comment on the Linux ALSA driver for USB MIDI that this adapter sends a faulty MIDI Run Status bit. That’s what’s causing legato notes to hang with this adapter. I never experienced this bug previously because I was always running that driver with Ubuntu.
  3. The Moog Subsequent 37’s onboard MIDI interface ALSO mistranslates echoed MIDI notes from DIN to USB when playing legato, often duplicating or tripling note-on messages with the same note value instead of recognizing additional notes. This was wreaking havoc on the MIDI module through no fault of the SSP.

Thank you @Handsonicsuki for your feedback.

@bert I apologize for my shortness. I’m sure you can imagine having 3 faulty test devices was extremely unexpected. If you wouldn’t mind keeping this bug report open until I can confirm success with the Roland adapter, I would appreciate it. I’m happy to post my complete troubleshooting methodology and results if it might benefit the community in some way.

1 Like

I received and tested the Roland UM-One MIDI interface today, and everything works perfectly with the SSP. The error I was experiencing can be attributed to faulty implementations in all my other USB-MIDI converters, as detailed above.

Thank you for your assistance. This bug report can be closed as a false-positive.


I’m glad to hear that UM-One worked well!

1 Like

great, i will order one and test & play too