Replies: 4 comments 27 replies
-
|
How are you trying to send the messages (which OS, tools etc)? Instead of doing it manually, you could try to use https://github.com/gmcn42/mt32-pi-control - you can use it on Amiga, Atari, DOS, Windows and Linux. Example: |
Beta Was this translation helpful? Give feedback.
-
Well, this build effectively gives the GPU something to do, so it's going to heat up when the log is being flooded and it has to redraw the screen. In a regular build with no display the GPU is idling, hence Pi is cooler.
Yes, for some reason we're receiving MIDI beat clock ticks. There's nothing really "wrong" with this; I'm guessing the intelligent mode card starts up in this mode. Can you provide any details on this card? What it is? I think my card (Music Quest clone) has a utility that lets you configure it, it may be possible to turn this feature off. Useless unless you're doing music production, otherwise harmless.
Not really. A MIDI beat clock is used to keep two sequencers' tempos in sync. We aren't a sequencer, so we aren't doing anything like that here, these messages are just ignored by mt32-pi. You send a note, the note plays immediately - that's it. A MIDI synthesizer does not need to "sync" anything. The "transaction failed" message indicates the USB driver has failed to send/receive a message to the USB device, which is more concerning. It can happen under normal conditions because of bug/limitations in the Pi's USB controller and/or the devices, although I think failed transactions are retried, so unless the screen is being flooded with these messages we can probably just ignore this for now.
We need to move a level further up. I'll create another build that prints the raw messages being received from the USB device - the one you just tested logs the output of the MIDI message decoder.
The game probably reconfigured the intelligent mode card and told it to cut it out with the sync messages.
Is it though? Compare a well-known, well-recorded soundtrack like Monkey Island and listen to it carefully for missing notes - like I said, I think failed transactions are retried so this may be okay.
You can attach them here by dragging them into the reply box, otherwise my email is
Pretty likely. In my experience this device has wildly mixed results as it seems there were a few revisions of it with different firmware/microcontrollers. If we can't get it working I'll just have to mark it as unsupported/YMMV - I've already worked with the upstream maintainer of Circle on trying to fix some issues with this device but they don't own one and now that mine's dead there's not a lot we can do. The UM-ONE MkII is, in my opinion, the gold standard of USB MIDI interfaces - it has been flawless in every situation I've used it in, and pretty much everyone else who's used one will probably tell you the same - totally solid investment. I'll give you another build to try shortly just to try and see whether any SysEx is making it into the USB receiver code. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you again. Here are the photos:
The intelligent mode card I have is a Music Quest clone by keropi from VOGONS called PCMIDI http://pcmidi.eu/index.html I believe it is 100% compatible with the Music Quest software including MQSETUP that initilizes the programmable features of the interface and sets up the metronome (clock signal I guess?) at reboot. I will look into this and try to disable that signal so that we don't flooded by it next time. I also have a lingering suspicion that this clock signal could be causing the constant sd card activity led and running very hot. It may even be interfering with the SysEx messages? I don't know. I've tried DOOM in GM mode and Monkey Island in MT-32 mode and I can't hear any missing notes, which I guess confirms what you are saying: The 0x202 errors are getting retried and fixed I'll be waiting for the more verbose build. Hopefully I can help you fix the issue :) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the photos! Yes, I have this card too - or rather, I used to, and then I switched to the Orpheus which also includes the MQ clone on-board. mt32-pi goes into a low-power mode when MIDI isn't received for some time, so sending it the beat clock constantly would prevent it from doing so. Here's a new build: https://github.com/dwhinham/mt32-pi/actions/runs/813197918 The previous logging has been disabled and now we should see the raw data from the USB MIDI receive interrupt. I've added a filter to ignore single-byte beat clock messages just in case you cannot disable them. Try to get captures of attempts to send isolated SysEx messages if you can, e.g. using the mt32-pi-control tool. Hopefully something will be revealed. |
Beta Was this translation helpful? Give feedback.
-
|
I come bearing.. bad news. First bad news: The midiquest does have a metronome feature but it's different from the midi clock that keeps being transmitted so I couldn't disable that. Regardless, your build seems to be perfectly ignoring those F8 commands (none displayed) and the pi is also running much cooler. The card activity LED is still always on, however. I don't know what causes this behaviour. Second bad news: The pi receives absolutely NO SysEx messages whatsoever. I sent several different messages (synth type change, reboot, reset, etc.) and there is absolutely not a single message on the onscreen log - it is as if the pi is receiving nothing from the usb interface in terms of SysEx. In the process I realized IRQ2 on my 486 was being hogged by the PCI bus so I moved the Intelligent Mode interface to IRQ3 anc disabled COM2, it did not help. MIDI seems to work fine either way, but SysEx just doesn't move through USB. For now I added two push buttons onto my case and these help me with changing synth type and ROM/SF2 on the fly, and I can live with that.
The UNO seems to be a lost cause? I don't know, I guess I may either end up getting the roland USB I/F in a few days or just order parts to build a couple mt32-pi-midi-hat control surfaces. I have one kind request from you though. Can you make the "Ignore single byte beat clock messages" thing a config toggleable option for the next build? Also, if I use the "kernels" from this last build as opposed to "kernels-hdmi" would that allow me to use this build as a daily without audio distortion? |
Beta Was this translation helpful? Give feedback.
-
By "ignore", I meant only in the test logging to stop the spam. The LED always being on is expected and fine, it means it's receiving data, no matter what that data is. I've done some digging and now I think I understand what's going on here. The Music Quest is supposed to be a faithful clone of the original Roland card, so let's see what the MPU-401 documentation says: So from this we know that an intelligent MPU is supposed to send beat clocks on power up, by design and we can stop worrying about it. It's up to software, whether that be a driver, TSR, game, sequencer etc, to turn it off.
Let's ask a different question - is the MPU sending any SysEx? The MPU-401 also has this command: From the wording, this command is meant to only affect SysEx being passed from the MIDI IN of the MPU to the MIDI OUT of the MPU and not from the host. But still, who knows? Dig carefully through all of the Music Quest drivers and make sure there isn't anything that tells the MPU to ignore SysEx. The Music Quest drivers seem to have a tool that can be used in your AUTOEXEC.BAT to configure things, have you investigated this? I don't have my old PC set up so I can't test right now. Also, it might be worth connecting the USB end of the Uno to a modern PC and using something like Pocket MIDI or MIDI-OX to see if SysEx is being received. If there's no SysEx there you can ignore mt32-pi and focus on fixing your DOS PC/MPU and/or the Uno. If there is SysEx when the Uno is on a modern PC, there is an issue with the Circle USB MIDI driver and the Uno, and it's not likely that I can fix it unless I buy another Uno (which I really don't want to do).
I could make the LED only light up on notes/CCs/SysEx and not for realtime messages like beat clock and active sense. I don't think this deserves a config option. It would also be purely cosmetic; there's no effect on the synthesizers. F8 and similar messages have always been "ignored".
Yes, exactly. "kernels" are the release kernels, "sdcard" is "kernels" plus support files. |
Beta Was this translation helpful? Give feedback.
-
|
It WORKS! The EXCLUSIVE THRU mode was the problem, as noted in that text it is indeed turned ON by default on startup. There is a small program called THRUOFF.EXE in the Midi Quest software package that turns this feature on, and now all SysEx messages get sent to the Pi and executed flawlessly. Thank you SO MUCH! Oh man I'm just ecstatic right now :D I can remove the ugly ass buttons. |
Beta Was this translation helpful? Give feedback.
-
|
Excellent - and no problem 🙂 So just to clarify, you needed to run THRUOFF.EXE before it began to work? |
Beta Was this translation helpful? Give feedback.
-
|
Yes, it worked fine after THRUOFF.EXE was run. However, after rebooting both, now it no longer works even after THRUOFF.EXE smh When I send SysEx after THRUOFF.EXE, the pi's activity light blinks, so at least now I know it's getting SOMETHING. I will put the HDMI kernel on and see what it reports after THRUOFF.EXE and report back, sorry for the premature display of joy :( |
Beta Was this translation helpful? Give feedback.
-
|
For me, using the -v switch makes mt32-pi.exe work, at least for a while after each reboot. After a clean reboot I seem to be able switch everything around this way for a while, and I don't know why. Possibly with the -v switch being verbose changes the timing of the SysEx being sent by a few ms or something? That may have the same effect as spamming the message maybe? Regardless, after using the pi for a while, the -v switch trick also no longer seems to work. I will resort to using DUMP and see if that is more reliable. If it works, I can just stick to DUMP and create my own custom .SYX files. Hopefully that will work :) Happy to be getting somewhere at least! I really appreciate the time you took on this. P.S. Do you post on vogons? |
Beta Was this translation helpful? Give feedback.
-
|
I think I've narrowed it down. To send the data from host PC to the MPU there's a handshake to put the MPU into UART mode, and then the data is fed into the MPU a byte at a time, reading its status registers in between each byte to check when it's ready to receive the next one. mt32-pi-control does appear to do this, but I think something's not right between the UART mode switch and sending the data. I've added a 1 second delay between the switch and when the data sending starts. For me, this "fixes" it - see attached test build: For you, adding -v must have created just enough of a delay by printing to the screen to fix it - the -v print happens after init is done and before data is sent. This needs fixing properly, but I can't see what's wrong and I have no experience with the quirks of programming the MPU401. If you test the build I attached and report back, I'll open a bug about this.
Very rarely, I tend to avoid forums due to lack of time these days. I am aware of the threads about mt32-pi and it's been great to see the builds people are putting together. Sadly there have been a couple of individuals who have exhibited harassing behaviour towards me via email who I have had to block from this GitHub repository, and they are participating in some of those threads, so I would prefer to keep a distance. Thanks for all the testing! |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for being so awesome and helping out with everything! I can confirm that with DUMP everything is working smoothly and I actually made a little batch file of my own to get around things, which I thought may be of interest or help to you or anyone reading this thread: Extract it to c:\pisetup\ and add to path, then whenever you call pisetup.bat changing mt32-pi settings is a breeze and works flawlessly. I will also test the build you posted and report back, and hopefully it works for me, so mt32-pi-control's dev can fix that bug as well. Thank you for such an awesome piece of software and for being so helpful, once again. |
Beta Was this translation helpful? Give feedback.
-
|
I tested your MT32-PI.EXE build and yes it does indeed appear to run and switch between modes and rom/sf2 files as intended. You saved me $40 and the hassle of building the midi-hat :) |
Beta Was this translation helpful? Give feedback.
-
This is very nice, thankyou!
My pleasure :)
That's great, thanks for confirming. I'll open an issue now. |
Beta Was this translation helpful? Give feedback.
-
|
I'm no expert but I've recent experience playing with mt32-pi. I wonder if the MIDI files attached here have any effect for you, if 'played' to the unit. And further note (without being sure of it's relevance-or-otherwise to your particular method) that the SYSEX in those instances contains a length byte following the F0, i.e. F0 7D 03 01 F7 -> F0 04 7D 03 01 F7. |
Beta Was this translation helpful? Give feedback.
-
|
The thread(s) above are quite long if you expand them, but the issue was solved (bug in the software used to send the messages).
The
If you do actually send |
Beta Was this translation helpful? Give feedback.
-
Ah that makes sense. My knowledge at this depth is entirely comprised of what I learned in order to quickly whip up those MIDI files in a hex editor after briefly researching the MIDI file format - fairly sparse. In that context the mt32-pi did not work without the length value (in hindsight because the MIDI file player would have required it upon parsing the file, in order to send the correct data to the pi), but I now stand educated on the fact that length byte is not part of the raw sysex standard outside of MIDI files, cheers. |
Beta Was this translation helpful? Give feedback.
-
I'm trying to get set mt32-pi to GM mode.
I'm sending it the SysEx message "F0 7D 03 01 F7" and I can see read activity for the SD card. This should presumably load the default SF2, I suppose, but does not. When I start doom with either General MIDI or Sound Canvas music settings I get music with wrong instruments, almost as if I was sending MIDI music to an MT-32.
If I select default renderer as fluidsynth via the config file, then I do get working General MIDI. But then I can't get it to rever to MT-32.
It's almost as if the pi is ignoring my SysEx messages. What could the issue be? I am using an M-Audio UNO USB MIDI interface. Should I fiddle with the baud rates? What could be going wrong?
Beta Was this translation helpful? Give feedback.
All reactions