I had not installed that update. I have now, and it's working as expected at 2400 baud for some Sunday night telnet BBSing.bbond007 wrote: ↑Mon Feb 22, 2021 2:19 amHave you installed this update?
https://misterfpga.org/viewtopic.php?p=17936#p17936
MidiLink.INI no longer defines the baud rate. It is now set by the OSD.
With CCGMS I was able to change the modem to 300/1200/2400 BAUDs...
FoxbatStargazer wrote: ↑Fri Feb 26, 2021 1:15 am Is there any way to lower the mixing quality of MUNT to try and shore up performance on a Pi or even Mister? Midilink has a MUNT options= line but I can't find documentation anywhere about what you can put there.
Code: Select all
-r : Enable reverb (default)
-n : Disable reverb
-m : Manual buffering mode (buffer does not grow)
-a : Automatic buffering mode (default)
-x msec : Maximum buffer size in milliseconds
-i msec : Minimum (initial) buffer size in m;
-l mode : Analog emulation mode (0 - Digital, 1 - Coarse, 2 - Accurate, 3 - Oversampled 2x, default: 2)
Code: Select all
root@DietPi:/opt# ./midilink UDPFSYNTH
-bash: ./midilink: No such file or directoryCode: Select all
root@DietPi:/opt# readelf -l ./midilink | grep interpreter
[Requesting program interpreter: /lib/ld-linux-armhf.so.3]
Hi,314ter wrote: ↑Mon Mar 01, 2021 12:04 pm I am failing to get Midilink to work on my rPi4. Got it to work on an Retropie installation, but I wanted something leaner, so I installed a Dietpi image on the rPi4 which is a lightweight Debian based OS.
https://dietpi.com/downloads/images/tes ... -Buster.7z
Note, I chose the 64bit (ARM v8) version.
When i try to run midilink the output is as follows:After a google search I tried:Code: Select all
root@DietPi:/opt# ./midilink UDPFSYNTH -bash: ./midilink: No such file or directoryThe midilink program is trying to use /lib/ld-linux-armhf.so.3, but I seem to be missing this...Code: Select all
root@DietPi:/opt# readelf -l ./midilink | grep interpreter [Requesting program interpreter: /lib/ld-linux-armhf.so.3]
The same is the case for mt32d (which I copied to /usr/bin)
Is there any way to get midilink to run on this (64bit) Dietpi distro?
I know, thanks, but I was the one who asked you for it at that time, and I am using your optimized compile now, to no effect I'm afraid.Alkadian wrote: ↑Mon Mar 01, 2021 1:40 pm Hi,
I have compiled Midilink optimised for the rpi4. Please see refer to my post below:
https://misterfpga.org/viewtopic.php?p=17150#p17150
(I don't have /lib/ld-linux-armhf.so.3 on my rPi4, Debian 64bit)Hmmm..maybe I just need to do a clean install. It sort of takes (sometimes) but usually I am just stuck on 2400 baud.
I did the original UDPMIDI.EXE in C# which was perhaps a bad choice as the MIDI API is using a lot of older (unmanaged) API's. As a result the code is pretty hacky.
The simpler approach is to redo the app in c/c++, so I have started to do that and have something working now if anyone wants to give it a try...
EDIT: 2.2 now supports sending.
Unfortunately my experience was much the same on a Rev.0 MT-32. Looking at the code that is responsible for delaying the messages in MidiLink, the timings seem to be quite different from how e.g. DOSBox implements this.ryanvb wrote: ↑Tue Feb 23, 2021 4:49 pm I've been trying for 2 days to get Space Quest 1 VGA or SQ4 to work on my MT32 without generating a "Exc. Checksum Error" message on the MT32 at launch.
I do have "DELAYSYSEX = TRUE" set in /media/fat/linux/MidiLink.INI which I thought was supposed to avoid these presumably speed related issues. I'm using the official Roland USB cable and a first-gen MT32.
Currently SoftMPU with DELAYSYSEX actually gets the job done for me, no need to limit the speed of the core or enabled the delay in MidiLink. The line I use to load it is simply:ryanvb wrote: ↑Tue Feb 23, 2021 4:49 pm DELAYSYSEX FALSE in MidiLink.ini. If it’s TRUE then music starts playing late, after the Sierra logo has displayed for a while. So there’s no need to have MidiLink slow down the transmission, disabling L1 cache already seems to do that well enough.
EMM386 MUST be enabled. With just HIMEM, the MT32 checksum error occurs at startup of both SQ1 and SQ4 (regardless of whether DELAYSYSEX is set in SoftMPU or MidiLink.INI, unfortunately).
Code: Select all
SOFTMPU.EXE /MPU:330 /DELAYSYSEXI did not look at any existing code before implementing that DELAYSYSEX function. I simply added more delays to the sysex messages until the checksum errors quit occurring on my Rev0.Vaelenthior wrote: ↑Wed Mar 09, 2022 5:06 pm First of all, I would like to thank bbond007 for the MidiLink service
Unfortunately my experience was much the same on a Rev.0 MT-32. Looking at the code that is responsible for delaying the messages in MidiLink, the timings seem to be quite different from how e.g. DOSBox implements this.
No need to apologize, I assume you wrote this in your spare time.
I think that's correct. Also, the dosbox-staging source code mentions this original discussion thread on the implementation: https://sourceforge.net/p/dosbox/patches/241/
I have this installed with the latest version of Raspian on a Pi 3B+ and an HDMI display. The sound is coming out the Pi instead of the display, but the desktop sound is coming out the HDMI device. Is there a way to launch midilink and make it use the HDMI device? Also, is the original tar file in this thread still what I should be using, or is there a newer version? Also, what performance settings for MidiLink do you recommend on the 3B+? This is on a new MiSTer setup using a Waveshare 11.9" screen which has an audio out jack on it that comes from the HDMI. In the Desktop, the audio device is called "HDMI". When I play youtube videos through it, it sounds choppy, so maybe MidiLink will too once it is working, and I might be better off with a DAC hat, but I want to try HDMI first. Thanks!
Its really been a while (and I was using RetroArch), but I thought that HDMI could be set it using the raspi-config utility. For my USB Turtle Beach and HiFiBerry I remember having to manually edit a file (maybe /etc/asound.conf)
Thanks! I did try the Raspi-config utility actually and it ended up breaking the display output and I had to reload the OS from scratch - that or it was me trying to install the driver for the display that it did not need so maybe that broke it even though the script said it wasn't needed- not sure which caused the problem. I appreciate all the tips, and I will give everything a shot until I figure it out, and it is no big deal to reload again if necessary. Edit: looking at the article, I saw the Mai item in Raspi-config thinking it was my Chinese made display, so that is what I selected. HDMI was not listed there. Hopefully the /etc/asound.conf will work or HDMI will be listed next time since I didn't try to install the display driver. If not I will just get a hat. I am mounting the screen in my arcade cabinet above the main CRT screen and the pi mounts behind it so I don't want it to be too thick. I think it will be ok though. Thanks again!
Update: I got it working, but I ended up getting a HiFiBerry anyway for hopefully the best sound quality, and still had the issue. The issue was running it as root with the ./sudo midilink... The root user did not have the default audio device that the pi user did.
Here are all the fixes and enhancements that I did (for future reference and to anyone else that wants to do this)...
To get the list of devices, type aplay -l:
pi@raspberrypi:~ $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: Headphones [bcm2835 Headphones], device 0: bcm2835 Headphones [bcm2835 Headphones]
Subdevices: 8/8
Subdevice #0: subdevice #0
Subdevice #1: subdevice #1
Subdevice #2: subdevice #2
Subdevice #3: subdevice #3
Subdevice #4: subdevice #4
Subdevice #5: subdevice #5
Subdevice #6: subdevice #6
Subdevice #7: subdevice #7
card 1: vc4hdmi [vc4-hdmi], device 0: MAI PCM i2s-hifi-0 [MAI PCM i2s-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: BossDAC [BossDAC], device 0: Boss DAC HiFi [Master] pcm512x-hifi-0 [Boss DAC HiFi [Master] pcm512x-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
Then to set the default audio device for root edit /etc/asound.conf and specify the card number of the BossDAC (2 in this case):
pi@raspberrypi:~ $ sudo vi /etc/asound.conf
pcm.!default {
type hw
card 2
device 0
}
Then to get it to launch automatically with a reboot, edit /etc/rc.local
pi@raspberrypi:~ $ sudo vi /etc/rc.local
(at the end before the exit 0)
cd /home/pi
./midilink UDPMUNT QUIET &
exit 0 <-- already there
reboot to test and hopefully it works in the background
Be prepared to have your ears blown off because it is very loud. To fix this:
pi@raspberrypi:~ $ sudo alsamixer
Press F6 to select the sound card BossDAC
Press Right Arrow until you get to Digital and change the volume to 50 with the Down Arrow
Press Esc to exit
Save it permanently:
sudo alsactl store
reboot
Also, I was getting Munt performance issues so I did some performance enhancements:
pi@raspberrypi:~ $ sudo vi /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
100
pi@raspberrypi:~ $ sudo vi /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
50000
pi@raspberrypi:~ $ sudo vi /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance
pi@raspberrypi:~ $ vi /home/pi/MidiLink.INI
MUNT_OPTIONS = -i 30
(keep all the other lines)
Now on my Raspberry Pi 3b+ I get much better Munt performance without as many stutters and no overruns, at least in Monkey Island 2. Hopefully someday I can get a Pi 4. I still get a bit of stutter occasionally so maybe I will try overclocking. Probably first, I will try a lighter OS like Raspberry Pi OS Lite, or maybe I can disable unnecessary services on the OS I have now.
I had previously used a windows emulator through wine (WinX68kHighSpeed_eng) and had beautiful output from the game Gemini Wing playing on my CM-64, since it has options to meld CM-32P PCM sounds with the CM-32L synth sounds.
Now, I've been trying to use USB-MIDI from the MiSTer's X68000 core and have been getting stuck notes galore in Gemini Wing with any of the CM-64 option keys F2-F4 held on game boot. This even happens when starting it in CM-32L/MT-32 mode by holding F1 while booting the game. The main synth sound freezes the moment it begins playing in the very first level, while the drums continue but otherwise only certain short tidbits are heard.
I haven't been at it long, but have tried turning off DELAYSYSEX in the linux/MIDILink.ini config file. It doesn't seem to change the MIDI output for Gemini Wing, although the CM-64 wouldn't ever need DELAYSYSEX set TRUE. I've also tried a couple Roland branded MIDI cables, as well as multiple USB adapters without any difference (Edirol UM-1S, Edirol UA-4FX, and Yamaha UW500). Finally, I've tested it with my CM-500 in its mode B (CM-64 simulation) too but it's the same.
The X68000 core is set through the OSD to use "USB" for the MIDILink option, and 31250 BAUD (with no other BAUD rate choices shown, but that should be correct for the X68000).
On the other hand, Acumajou Dracula sounds perfect, through all of these setups and cables.
A tip if you're trying this: Sharp X68000 games boot fast from .HDF SASI hard drive images.
Thanks for any further suggestions or solutions!
I investigated the X68000 core's Gemini Wing MIDI output by running it through a computer running aseqdump, and I get drastically corrupted SysEx messages. During the initial loading of the F4-held SN-U110-07 mode which should have most SysEx messages as 256 bytes each (according to the emulator's output and verified CM-64 playback), from the MiSTer they are all 22 bytes each and they don't even appear to be messages for the MT-32 family, which should begin with "F0 41 10 16 12".
A few entire-message examples of these corrupted messages follow:
F0 41 10 20 00 32 06 0C 29 00 00 5A 5C 00 64 00 05 00 32 00 1B F7
F0 41 10 6E 00 32 00 0C 2E 32 00 52 61 00 00 00 00 00 32 00 0C F7
F0 41 10 61 3C 32 20 0C 49 32 64 3C 36 01 0F 64 32 3C 31 18 0C F7
An example good message (the first 256-byte Initial-SysEx message) from the emulator follows:
F0 41 10 16 12 08 00 00 52 45 45 44 31 20 20 20 20 20 00 00 03 00 24 37 0B 01 01 00 21 07 00 00 00 00 00 34 00 32 32 32 32 32 00 00 00 64 0A 01 27 08 18 64 00 00 06 14 21 4D 53 2D 45 4C 00 64 4A 59 0C 19 0C 00 00 00 00 00 00 2B 64 64 64 64 24 29 0B 01 01 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 00 00 64 10 0E 67 06 00 08 00 00 00 00 00 00 00 00 00 00 00 5A 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 24 2F 0B 01 00 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 17 38 64 10 05 67 06 00 00 00 00 00 00 00 00 00 00 00 00 00 46 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 24 2F 0B 01 00 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 17 38 64 10 05 67 06 00 00 00 00 00 00 00 00 00 00 00 00 00 46 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 77 F7
But that's not all I noticed: After the game has been opened from the menu by selecting "Game Start", normally as the music starts for the first level there are a few SysEx messages in certain parts of that level's song which repeat when the song loops. They don't appear to play at all on the MiSTer's X68000 core.
That's the easily noticed corruption for me to see, but I suspect it may even be corrupting the note off messages as that's the reason I questioned it working in the first place as that aspect is obvious though audio.
EDIT: I created an issue at the github tracker: https://github.com/bbond007/MiSTer_MidiLink/issues/9
jaffa225man wrote: ↑Tue Oct 03, 2023 5:18 amI investigated the X68000 core's Gemini Wing MIDI output by running it through a computer running aseqdump, and I get drastically corrupted SysEx messages. During the initial loading of the F4-held SN-U110-07 mode which should have most SysEx messages as 256 bytes each (according to the emulator's output and verified CM-64 playback), from the MiSTer they are all 22 bytes each and they don't even appear to be messages for the MT-32 family, which should begin with "F0 41 10 16 12".
A few entire-message examples of these corrupted messages follow:
F0 41 10 20 00 32 06 0C 29 00 00 5A 5C 00 64 00 05 00 32 00 1B F7
F0 41 10 6E 00 32 00 0C 2E 32 00 52 61 00 00 00 00 00 32 00 0C F7
F0 41 10 61 3C 32 20 0C 49 32 64 3C 36 01 0F 64 32 3C 31 18 0C F7An example good message (the first 256-byte Initial-SysEx message) from the emulator follows:
F0 41 10 16 12 08 00 00 52 45 45 44 31 20 20 20 20 20 00 00 03 00 24 37 0B 01 01 00 21 07 00 00 00 00 00 34 00 32 32 32 32 32 00 00 00 64 0A 01 27 08 18 64 00 00 06 14 21 4D 53 2D 45 4C 00 64 4A 59 0C 19 0C 00 00 00 00 00 00 2B 64 64 64 64 24 29 0B 01 01 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 00 00 64 10 0E 67 06 00 08 00 00 00 00 00 00 00 00 00 00 00 5A 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 24 2F 0B 01 00 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 17 38 64 10 05 67 06 00 00 00 00 00 00 00 00 00 00 00 00 00 46 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 24 2F 0B 01 00 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 17 38 64 10 05 67 06 00 00 00 00 00 00 00 00 00 00 00 00 00 46 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 77 F7But that's not all I noticed: After the game has been opened from the menu by selecting "Game Start", normally as the music starts for the first level there are a few SysEx messages in certain parts of that level's song which repeat when the song loops. They don't appear to play at all on the MiSTer's X68000 core.
That's the easily noticed corruption for me to see, but I suspect it may even be corrupting the note off messages as that's the reason I questioned it working in the first place as that aspect is obvious though audio.
EDIT: I created an issue at the github tracker: https://github.com/bbond007/MiSTer_MidiLink/issues/9
Have you (or perhaps someone else) tried it with an mt-32pi? I'm just wondering if that game has the same behavior with the X68000 core using an entirely different way of interfacing with MIDI (USER IO) which would let us know if MidiLink was at fault or if the problem is with the core itself...
I'm a complete X68000 nube...
bbond007 wrote: ↑Wed Oct 04, 2023 1:28 amjaffa225man wrote: ↑Tue Oct 03, 2023 5:18 amI investigated the X68000 core's Gemini Wing MIDI output by running it through a computer running aseqdump, and I get drastically corrupted SysEx messages. During the initial loading of the F4-held SN-U110-07 mode which should have most SysEx messages as 256 bytes each (according to the emulator's output and verified CM-64 playback), from the MiSTer they are all 22 bytes each and they don't even appear to be messages for the MT-32 family, which should begin with "F0 41 10 16 12".
A few entire-message examples of these corrupted messages follow:
F0 41 10 20 00 32 06 0C 29 00 00 5A 5C 00 64 00 05 00 32 00 1B F7
F0 41 10 6E 00 32 00 0C 2E 32 00 52 61 00 00 00 00 00 32 00 0C F7
F0 41 10 61 3C 32 20 0C 49 32 64 3C 36 01 0F 64 32 3C 31 18 0C F7An example good message (the first 256-byte Initial-SysEx message) from the emulator follows:
F0 41 10 16 12 08 00 00 52 45 45 44 31 20 20 20 20 20 00 00 03 00 24 37 0B 01 01 00 21 07 00 00 00 00 00 34 00 32 32 32 32 32 00 00 00 64 0A 01 27 08 18 64 00 00 06 14 21 4D 53 2D 45 4C 00 64 4A 59 0C 19 0C 00 00 00 00 00 00 2B 64 64 64 64 24 29 0B 01 01 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 00 00 64 10 0E 67 06 00 08 00 00 00 00 00 00 00 00 00 00 00 5A 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 24 2F 0B 01 00 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 17 38 64 10 05 67 06 00 00 00 00 00 00 00 00 00 00 00 00 00 46 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 24 2F 0B 01 00 00 00 07 00 00 00 00 00 34 00 32 32 32 32 32 40 17 38 64 10 05 67 06 00 00 00 00 00 00 00 00 00 00 00 00 00 46 46 5B 0C 1B 0C 00 00 09 05 0B 0E 0F 4D 5C 62 64 77 F7But that's not all I noticed: After the game has been opened from the menu by selecting "Game Start", normally as the music starts for the first level there are a few SysEx messages in certain parts of that level's song which repeat when the song loops. They don't appear to play at all on the MiSTer's X68000 core.
That's the easily noticed corruption for me to see, but I suspect it may even be corrupting the note off messages as that's the reason I questioned it working in the first place as that aspect is obvious though audio.
EDIT: I created an issue at the github tracker: https://github.com/bbond007/MiSTer_MidiLink/issues/9
Have you (or perhaps someone else) tried it with an mt-32pi? I'm just wondering if that game has the same behavior with the X68000 core using an entirely different way of interfacing with MIDI (USER IO) which would let us know if MidiLink was at fault or if the problem is with the core itself...
I'm a complete X68000 nube...
Thanks for responding so quickly! Yes, I was considering that it could be the core too, but at least I know Akumajou Dracula is working (on both the X68000 core and MIDILink).
I'm a complete newbie with the X68000 too, and also the MiSTer, but had to try the system & game I wanted it for most, as soon as possible. I still have to try my long lost childhood system too: the Commodore Amiga.
And, although I don't know if anyone else has tested it with the mt32-pi, I don't have one to do it myself as I've been holding out for when it becomes possible to have a full MT-32 interface with all its buttons, encoder, LCD, and IN/OUT/THRU ports. For the interests of discovering this, though perhaps it will be worth buying one sooner... Of course, if there's a way to connect to the USER IO port to debug it without having an mt32-pi, I wouldn't mind trying that either. Would the "MiSTer MIDI" (1.4), which connects to the IO Board's USER port, work the same way but allow my real Roland devices to be used? I should probably just get one because I wasn't aware they existed until now, and am anticipating you'll say yes. It will be nice not tying up a normal USB port to MIDI usage too.
However, I won't mind if someone else who already does have the mt32-pi, tries running the X68000 core's Gemini Wing in MT-32 mode by booting the SASI .HDF image of the game while holding F1 on a connected USB keyboard. The music is pretty obviously wrong with the stuck notes if it isn't working on the core, and if it sounds good it must be working on the X68000 core.
Hi there,
I'm also using a UM-ONE mk2 USB cable with my original Roland CM-32L device.
Gemini Wing and other Sharp games used to play Midi just fine on the X68000 core a couple years ago with my setup.
Seems Midi got messed up in most X68000 games by a newer version of the core.
jaffa225man wrote: ↑Wed Oct 04, 2023 3:30 amWould the "MiSTer MIDI" (1.4), which connects to the IO Board's USER port, work the same way but allow my real Roland devices to be used? I should probably just get one because I wasn't aware they existed until now, and am anticipating you'll say yes. It will be nice not tying up a normal USB port to MIDI usage too.
I'm pretty sure it would work. Would defiantly be nice to be able to use my MIDI modules and TCP/Modem simultaneously.
It may not fix the issue with Gemini Wing though. I guess it depends if the core issue is isolated to using the UART for MIDI or if the exact same thing will happen with the "MiSTer MIDI" (1.4) interface.
Gryzor wrote: ↑Wed Oct 04, 2023 11:46 amHi there,
I'm also using a UM-ONE mk2 USB cable with my original Roland CM-32L device.
Gemini Wing and other Sharp games used to play Midi just fine on the X68000 core a couple years ago with my setup.
Seems Midi got messed up in most X68000 games by a newer version of the core.
Thanks for confirming that! I wonder what update specifically broke it, but maybe I can try some older versions in the meantime. I'm too lazy right now, though, and really enjoying reliving my Amiga 500/1000 days. I have ordered the MiSTer MIDI 1.4 to try later too.
bbond007 wrote: ↑Wed Oct 04, 2023 5:17 pmI'm pretty sure it would work. Would defiantly be nice to be able to use my MIDI modules and TCP/Modem simultaneously.
It may not fix the issue with Gemini Wing though. I guess it depends if the core issue is isolated to using the UART for MIDI or if the exact same thing will happen with the "MiSTer MIDI" (1.4) interface.
I don't know what I'd be using a modem for these days (BBSs maybe, but I only connected to our library once then). Anyway, yes, I can even see all 7 of the hub's USB ports getting used someday. This topic seems to be the origin of the MiSTer MIDI: viewtopic.php?t=910 and it seems to suggest it's connection is less abstracted than a USB-MIDI adapter. If I end up using this board for MIDI (which is great if it works with zero-latency), I feel another desire coming on: another USER PORT, but I know this is non-USB serial and a USB hub connected to it would be incompatible, useless, and worse - detrimentally destructive. SNAC for controllers might be nice someday, although I suppose, not for systems that use external MIDI thankfully. 
Great, please report back if your results are different without using MIDI though USB. That information cold potentially help a developer identify the regression and fix the issue.
jaffa225man wrote: ↑Thu Oct 05, 2023 4:08 amThis topic seems to be the origin of the MiSTer MIDI: viewtopic.php?t=910 and it seems to suggest it's connection is less abstracted than a USB-MIDI adapter.
Perhaps it does have less latency, but I can't tell the difference between USER IO, USB or even UDP(over WiFi) with my ears. I'm not a musician.