3

Essentially, I want to make recordings with my electric piano, using MIDI.

I connected my digital piano to my laptop with a MIDI to USB audio interface, and the following happened:

  • When pressing a key on my MIDI device and monitoring it in Midi-OX, it takes a long time (about 4 seconds) before it registers another input. I am not talking about the delay between pressing a key and registering in Midi-OX, but the delay between pressing a key and registering another key. A "cool-down period", so to speak, before it recognizes another input.
  • “Note Off” events are sporadic and often missing entirely.
  • It is noteworthy that the pedal works in real time, and when pressed, it resets the "cool-down time" between two notes.

My "setup" is the following:

  • I use a Yamaha P-35 digital piano. I know it's not the latest model, but it has MIDI input and output ports and should have no problems with MIDI transfer. (user manual: https://europe.yamaha.com/files/download/other_assets/8/328158/p35_en_om_a0.pdf)
  • The cable is an M-Audio Midisport Uno, which is not a cheap piece of junk from wish.com, in fact it cost me about 30€.
  • The laptop (Asus VivoBook14) runs Windows 11.

Of course, I searched the internet for answers and found other people facing the same issue, but nothing proved helpful. I tried a promising solution (https://sound.stackexchange.com/questions/27743/midi-input-3-second-delay-lag): sending SysEx messages via Midi-OX. I easily found the MIDI reference for my device (https://uk.yamaha.com/files/download/other_assets/6/328156/p35_en_de_fr_es_mr_a0.pdf), and sent a General MIDI Mode On message, but the issue remained unresolved. Perhaps MIDI codes could provide a solution, but as an absolute beginner, I have no knowledge or experience with them.

I hope that this issue can be solved by changing a few settings and not having to buy new equipment. This situation is extremely frustrating, it makes me feel like I’m just wasting my time. I would appreciate a useful answer. Thank you in advance.

5
  • 1
    Try different components to find where exactly the problem is. Does the Yamaha do the same with other MIDI devices? How about a different USB-MIDI interface? Try connecting the Yamaha to a MIDI synth with plain din MIDI and no USB and no computers anywhere. Try a different MIDI cable. Dec 28, 2023 at 18:01
  • 1
    Duplicate of music.stackexchange.com/questions/116973/…
    – user96057
    Dec 28, 2023 at 18:12
  • Looks like MIDI-OX has last been updated in 2011 and even back then it was written for older version of Windows. Microsoft incredibly backwards compatible compared to other systems but still I would try a different app or suitably ancient computer.
    – ojs
    Dec 28, 2023 at 18:30
  • FYI, 30 euros is cheap, in the relative sense. A quick search revealed popular MIDI interfaces costing $250, $400, and $1200, but the same manufacturer makes one for $37. The more likely concern for the interface is not the cost but the quality of the drivers. Dec 29, 2023 at 2:06
  • I doubt MIDI-OX is causing any issues, but if you want to try a MIDI monitor tool that has been updated more recently than MIDI-OX, perhaps consider Pocket MIDI.
    – Bavi_H
    Dec 29, 2023 at 17:22

2 Answers 2

8

TL;DR: whatever is the cause for this problem, it will very likely be fixed by using a different USB MIDI adapter.


This problem seemed so familiar and now I remembered what it was: running status. The Yamaha is using running status, and some component somewhere down the line, maybe the M-Audio box or something, doesn't handle running status. Sending a sustain pedal CC message resets the status, which allows one more key press i.e. Note-On to be handled by the dumb recipient device or software, whatever it is. And the five seconds or whatever, that's some kind of a timeout for running status for the Yamaha keyboard.

Either make the Yamaha not use running status (if possible), or use a less dumb receiving device or software, whichever component it is that can't handle running status.

Maybe I should add that running status is a basic standard MIDI feature, and not handling it is really ignorant. A program or device which claims to accept MIDI, but gets its internal logic messed up with running status, is not well made at all.

Edit2.

  • Running Status is meaningful over plain old 5-pin DIN MIDI, where things are transferred byte-by-byte. Not sending redundant (unchanged) status information saves a byte.

  • Over USB-MIDI (which is relevant IF this M-Audio Midisport Uno is "class compliant"... which I don't know), there is (at least usually, see below) no running status, because events are transferred as 32-bit messages, Event Packets. If I understood correctly, it is the USB MIDI adapter's responsibility to parse the incoming 5-pin DIN MIDI (or nowadays maybe TRS MIDI) data into such full 32-bit Event Packets. An entire Note-On event, complete with channel, note number and velocity, goes into a single 32-bit Event Packet. Similarly for a Control Change event. Some bits may be left unused in such an Event Packet, but they are all 32 bits, 4 bytes a piece, zero-padded. See https://www.usb.org/sites/default/files/midi10.pdf (Universal Serial Bus Device Class Definition for MIDI Devices Release 1.0 Nov 1, 1999)

  • (However, there seems to be a possibility for transferring single bytes unparsed i.e. one individual byte for each 32 bit Event Packet... Could the Midisport Uno use this, and leave the Running Status parsing logic for the application side? See Note2 on page 17 of the PDF above)

  • There are reports of Running Status handling problems with the Midisport Uno:

From these bits of information I conclude that very likely, the culprit must be the M-Audio Midisport Uno device.

Either the Midisport Uno is messing up the running status parsing, OR it is sending everything over to software side as Single Byte Event Packets (IF it is class compliant), and then the drivers or application software mess it up.

Whatever the case is, using an actually class-compliant, standards-compliant, normal, known good USB-MIDI interface will fix the problem.


One more edit. It seems that the Midisport Uno, like the 2x2 and other models based on the same EZ-USB AN2131SC microcontroller, require a "firmware" to be pushed into the device. And because the microcontroller has no flash memory, the firmware needs to be re-uploaded by the host every time the device is plugged in. Unplug it, and the firmware is gone. (Not very "firm", is it.) There is a GPL-licensed firmware version (written in 2001-2002) that seems to have support for Running Status. It's primarily intended for Linux, but maybe it could be used as a replacement in Windows as well, if M-Audio's firmware doesn't work properly? :)

I have to wonder, how come M-Audio is still selling this ancient device that isn't even class compliant and needs a driver. And people are willing to pay 30€ for it.

7
  • 2
    Good catch. I'd be most inclined to blame Midi-OX… last update was 12 years ago. It still says it's designed to run on Win 95 all the way up to …winXP :\ Might be time to look for something newer - random google of 'free daw' - midination.com/daw/free-daw/best-free-daw
    – Tetsujin
    Dec 28, 2023 at 19:12
  • 1
    I think it's unfair to blame MIDI-OX without proof. However, I also cast suspicion without proof: For non sysex messages, I think the USB MIDI protocol must gather bytes of a DIN MIDI message into one USB MIDI packet. Yamaha keyboards often send MIDI Clock and Active Sensing. A USB MIDI cable seeing MIDI Clock or Active Sensing might wrongly forget the running status? If so, the solution is another USB MIDI cable. In the "duplicate" question, the poster eventually reported some USB MIDI cables worked and some didn't. USB MIDI issues are frustrating, I wish we had tools for detailed testing.
    – Bavi_H
    Dec 29, 2023 at 15:31
  • 1
    Idea to test (or workaround) if the problem is caused by incorrect Running Status processing. On the Yamaha P-35, follow the instructions in the manual to layer two voices (Dual mode). In Dual mode, when you press a key on the keyboard, the same pitch will be transmitted on two MIDI channels (by default, channel 1 and 2). If the Yamaha P-35 consistently sends messages in the order of channel 1 note start, channel 2 note start, channel 1 note end, channel 2 note end, then Running Status (omitting the status byte of a channel message if it is the same as the previous message) will not happen.
    – Bavi_H
    Dec 29, 2023 at 15:32
  • clock & sensing shouldn't upset any midi device made since the 90s. Sure, it was an issue in the early days, but it shouldn't be any more. It's so long since I actively worked with midi for a living that I've forgotten half of it… including where I put my Soundcraft Midi tester:\ That would tell you everything going down a cable; not as discrete data, but just as lights for all the common structures, sysex, running status, CCs, PB/MW etc. I used to just capture output for analysis in Cubase or Logic - both capable, if you switch off the default 'consumer-friendly' filters.
    – Tetsujin
    Dec 29, 2023 at 18:15
  • 1
    @Tetsujin From what I can see without testing the actual setup in question, either the Midisport Uno is messing up the running status parsing, OR it is sending everything over to software side as Single Byte Event Packets, and then the drivers or application software mess it up. I don't know how common such Single Byte processing is. I had read the USB-MIDI spec before and I've made some USB-MIDI Arduino contraptions of my own, but I hadn't noticed such a special case provision before. Dec 29, 2023 at 21:29
1

[PROBLEM SOLVED] For those who are struggling with a similar problem:

I decided to give the MIDI-USB interface one last try, and by pure coincidence it happened to work.

What I did was I accidentaly left my keyboard in "Dual mode" (two voices layered) and it actually started working properly. I have no idea why. (Note: When using certain voices, you may hear what you are playing in two octaves, but you can find how to change this setting in the user manual.)

Hopefully it will help others too :)

1
  • 1
    I previously suggested enabling Dual mode to test. In Dual mode, the piano sends notes on two different MIDI channels and it's likely messages will alternate channels so Running Status (omitting a Status byte) can never happen. Now we know that Dual mode does prevent the problems, that suggests to me that your USB-MIDI cable is incorrectly handling Running Status, probably after a MIDI Clock or Active Sensing message. You might consider finding another USB-MIDI cable that correctly handles Running Status.
    – Bavi_H
    2 days ago

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.