Invalid messages and hanging notes

[ktesibios2]

Hello all, I have resumed my 4x4 interface thanks to this new driver; thank you for having provided it. It works with my system, but I'm experimenting frequently hanging notes. I'm using a MacBookAir with M1 processor, OS Ventura 13.6.1, with MainStage 3.6.6 and/or Logic Pro 10.7.9 (trial version), both in Rosetta mode. The 4x4 is connected with two keyboards, used as MIDI master, and a FCB1010 foot controller. I tested the system with Midi Monitor, and I found that very often invalid codes are sent from the interface, apparently deriving from Midi messages' corruption, which results in hanging notes when a note off event is corrupted. From time to time note on events get corrupted as well, resulting in ineffective key strokes. All devices work well with another single Midi interface I have.

Any suggestions or workarounds? May it depend from incompatibility with the M1?

Thank you for your attention Leonardo

[aleksibovellan]

@ktesibios2 I have that exact same problem. Usually after a boot, the pushed keyboard notes and their timings are random, when looked in MidiView. Almost like watching an arp playing some pattern. The only solution I have found is that I need to manually unplug and replug the 2x2 after the boot is finished. With doing that, the problem usually goes away. But if I'm unlucky it might return later at some point, so then I just have to unplug and replug again. Running OS Sonoma 14.4.1 in iMac M1. Hopefully one day this might get fixed. But if not, I just want to thank @leighsmith for what this software is already, I guess pretty much the only option for these interfaces these days in MacOS.

[leighsmith]

I'm not seeing the problems reported, on MacOS 14.4.1 on an Intel MacBook Pro.

Do you continue to see the problem if you start up the Apple Audio MIDI Setup.app tool, select Window->Show MIDI Studio and then rescan the bus with command-R?

One tool which is helpful to diagnose what is being received is to run MIDI Monitor and view and capture a notated dump of what is being received? It will help immeasureably to reduce the number of software tools in the chain which can contribute to problems, so you can isolate what is causing the issue. I'm concerned about running the DAW software in Rosetta mode - that seems like a potential cause of problems. The v1.3.1 MIDISPORT driver is a fat binary, running natively on Intel and ARM, and so is MIDI Monitor, so if you are still seeing problems running on M1 with just the driver and MIDI Monitor, then we have isolated the problem to the driver. Until we establish that fact, there are too many other variables at play to fully diagnose the problem, remotely.

[aleksibovellan]

Hi @leighsmith , and thanks a lot for taking the time to dive into this. That's just fantastic.

OK here are as much details, and screenshots, I could get right away, that might be useful.

PRE-TASKS DONE:

iMac M1 with OS Sonoma 14.4.1 and USB Midisport 2x2 Anniversary

No previous M-Audio drivers installed Installed the latest v.1.3.1 MIDI driver package from this GitHub Rebooting always with internet enabled

SYMPTOMS

This phenomena occurs after a fresh boot. Throughout this whole description below, the USB 2x2 MIDI interface keeps "breathing" slowly with its LED all the time, just as an observation. Also please note, that the keyboard used here is Roland JP-8000, so it sends 2 MIDI channels exactly simultaneously for each key press. Perhaps that's actually a good thing for these timing analysis purposes.

Anyway,

If I fast-tap a keyboard note only once - like a really, really quick tap - it looks from MidiView and Midi Monitor, that the note ON is received pretty much right away, but the final note OFF is randomly delayed for some reason. Almost like the end-part of that note message-pair is first stuck in some internal memory buffer, and only then released.

Sometimes though, the note ON message might be delayed also, as might its subsequent messages, and the actual note letter might also be identified as some other note. At worst, it might be like looking at some ARP pattern playing for a few seconds with slow timings.

INTERESTING BIT?

However, here is the interesting bit. If I fast-tap that same keyboard note many times repeatedly, like "tap tap tap tap", all those note messages seem to actually flow correctly with their ON and OFFs, up until the last pushes. Those last Note messages are then delayed and all over the place again. (Picture is attached of this test with a single push, and then repeating - the timing intervals are revealing). It's almost as if that repeating note-pushing "forces" the MIDI data to move along correctly. And when the physical pushing is done, then the final timings start to get lazy and drunk again.

There is no change in behavior, if I for example first start up the "Audio Midi Setup" and refresh the device list. In that "Audio MIDI Setup" window, the 2x2 MIDI interface looks to be identified correctly and working, from that view. (Picture attached)

ONLY FOUND SOLUTION SO FAR

This problem so far gets resolved, if I unplug the 2x2 from USB, and then replug it. Then all MIDI notes flow correctly and in a timely fashion. Also the LED keeps "breathing" after this also. I guess if we could somehow make that "unplug-replug" procedure work, for whatever it actually does there to solve the problem, as some delayed function after reboot, or something, that could be a way around having to manually unplug anything. But it would not of course explain what is happening in the first place, and what that physical unplug-plug procedure corrects after the reboot.

Thanks a lot, and all the best. :-)

[leighsmith]

Ok, the first task is for us to determine exactly what version of the hardware and what firmware should be downloaded to it. Use the /Applications/Utilities/System Information.app to determine the MIDISPORTs on the USB bus, look for "Composite Device" and post the Product ID and Vendor ID, the latter should be "0x0763 (M-Audio)". The next thing to do is verify the problem is not related to the MIDI keyboard, I would try another MIDI device that is known to work correctly.

Regarding the unplugging and plugging behaviour: Most of the MIDISPORT models do not have an application ROM within them, only a generic EZUSB boot loading ROM. So when the MIDISPORT is first plugged in, it is a generic EZUSB device. The firmware downloader which is installed to /usr/local/libexec/MIDISPORTFirmwareDownloader watches for such EZUSB devices with the M-Audio Vendor ID, and when it is reported, downloads the firmware matching the reported product ID. The MIDISPORT's EZUSB boot ROM then executes the new firmware, which is responsible for slow pulsing the activity LED, responding to received MIDI messages and sending them as MIDISPORT specific (non USB MIDI Class standard messages) USB messages which are interpreted by the open source driver.

The fact that you see the pulsing LED indicates the firmware is being properly downloaded and run (although it's possible the firmware doesn't properly match the product ID, hence my request for you to post the product ID). So the problem is either in the firmware, or more likely, in the USB device driver which is responding to the MIDISPORT specific messages.

Since there are many examples of this working in other contexts, it's worth eliminating possible problems from other causes, such as the MIDI keyboard, and the software, hence the suggested use of multiple versions of each.

[aleksibovellan]

Thanks @leighsmith for your informative reply, it was very educating. I had no idea how these protocols work. And also sorry for my delay.

The MIDI keyboard itself has been checked and it's working properly. Here is a screenshot of my USB tree, and the details of the Midisport 2x2 in it. It would be interesting if the product ID could be somehow related to this phenomena.

Hopefully this attachment might help, and I'll provide what ever else you might need. Thanks.

[aleksibovellan]

Added observed behavior:

If iMac M1 idles too long, and goes into screensaver, or even to sleep, in both situations the MIDI functionality of 2x2 stops. No input or output MIDI traffic anymore in MidiView and such monitors. The problem then requires a simple USB unplug-replug, and it comes back alive normally.