-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bad SysEx can cause mt32-pi to hang #25
Comments
Hi there! These cables are known to corrupt SysEx data [1, 2, 3], and it looks like Most MT-32 games send SysEx data to setup instrument mappings and parameters before the music begins, and if this is not received, the music will sound wrong. My guess is that the start of the data is received, which I can improve this behaviour so that when a limit is reached it throws away the garbage, displays a warning, and goes back to the usual state of expecting notes, but this does not fix your cable, and the music will still sound incorrect. The real fix is to invest in a quality MIDI cable like the ones we recommend. There is one thing you can try though - you didn't mention your source configuration. Is it Windows and ScummVM? Linux has some USB MIDI driver workarounds [1, 2] to try and sidestep problems with these cheap cables. Can you try a Linux machine as a source with the USB cable? |
Thanks, I was expecting that the cheap usb midi cable would be the reason. I'm using Windows, Dosbox and games from gog.com. |
Great, yes DOSBox on Linux would be a good test. I've looked into to proper way to handle SysEx problems from the MIDI specification, so whilst the cable is probably at fault, Thanks for your report! |
Works perfecly on a Linux machine :) Just had to use pmidi -l to get the device (20:0) and add it to the dosbox configuration. Anyway I ordered the recommended Roland cable so I can use it in Windows, too. Thanks a lot. |
Excellent! Thanks for testing this. This is valuable information, I'm not sure if many people realise these cables may be salvageable if used on Linux, so I think I'll add this to the README or a wiki page. I'll create a test build for you to try soon that should fix the getting stuck issue. 🙂 |
Hi there! I've done a pretty big rewrite of the MIDI parser and it should handle faulty SysEx better now. Could you try your cheap cable under Windows with this build? The instruments will sound strange as the SysEx is of course still going to be broken because of the flaws in the cable's firmware, but It'd be great if you could confirm things are still good on Linux with this version too. Thanks! |
Yes, it's working somehow now with the cheap cable and Windows 10: And here's Linux, seems to work just fine: |
Excellent, thankyou for making the videos and testing this! It's very interesting to know that the cheap cables can be used more reliably with Linux. Hopefully the new MIDI parser will still work reliably with the "good" cables too - it works for my M-AUDIO USB Uno but I'd like to know how it works with the Roland because that interface uses Running Status (for higher efficiency), and I don't have one of those for testing. |
I'm using pi-midi and cheap midi adapter. The problem is as follows: when starting a game I need to restart the Pi to get sound out of it.
Here's a demonstration: https://www.youtube.com/watch?v=gb6bEEK0EP8
I start the game at 00:12, and the game starts to send signal almost immediately (don't mind the label IN, it's wrong).
Then at 00:23 I unplug the pimidi's power and plug it back at 00:26. After restarting the sounds are played just fine and display updates. I tested with the gpio_thru option and the data is moving around even if there is no sound and the green led on Pi is not flashing.
Any ideas where the problem could be?
The text was updated successfully, but these errors were encountered: