MIDI-out, instruments don't initialize properly

[riggles1]

Using Roland SCVA and MUNT everything turns into piano's as mentioned at the end of this bounty.
libretro/RetroArch#6908

Instruments initialize properly with DOS and other things.
Adding it as an issue here as the MIDI feature is now implemented into the core, just not fully functional yet.

[riggles1]

@negativeExponent

We have an update on what may be causing this bug.

Nawell found the following info:

"When sending MIDI PC (program change) messages to set the instruments, the core sends two PC messages for each channel. The first one has the correct value, but the second one is a 00 value that defaults to a piano sound. That's the reason why all instruments ends up sounding like pianos. With MIDI-OX you can log the core's MIDI output, and clearly see the issue."

https://cdn.discordapp.com/attachments/434713532341288961/1159953985235582976/px68k_midi_bug.PNG?ex=6532e654&is=65207154&hm=102e5379e8142dc0824138e4ed702d6d0a39e728b824973010b8923dbdf62ad4&

[biffrapper]

Sadly this has yet to be fixed even though this is a core breaking bug.

[negativeExponent]

@biffrapper add anything more useful than repeating the issue.

@riggles1 how can this be confirmed. i know that midi works with fluid.timity,munt through libretro api, though i dont have a comparison of how its suppose to sound on each setting, at least on my fork of px68k. i did notice a difference with using libretro api that it somehow add delay, or drop notes at the beginning when using timidity. and somehow if using fluidsynth directly in px68k lessens these said delays as well. as for sounding just pianos, dont think it does. i can only test through software midi(or whatever its called) under linux.

[riggles1]

@negativeExponent Not sure, both munt and roland va work perfectly for libretro dos. No idea why instruments aren't initialized properly here, all instruments seem to play well other than being only pianos. Win10 64bit.

[negativeExponent]

@negativeExponent Not sure, both munt and roland va work perfectly for libretro dos. No idea why instruments aren't initialized properly here, all instruments seem to play well other than being only pianos. Win10 64bit.

it would be helpful if you can post sound samples. im not entirely sure of what is suppose to be the correct initialization. but i dont hear pianos here. unless im using munt (mt32) for example, and use Standard in libretro api's midi interface and use GS/GM/SC-55 device in game config like Akumajou Dracula.

also helpful would be the synth used and its config its its other than default, including soundfont used. i myself turn off reverb and echo in my settings coz its just annoying to listen sometimes.

thanks for the reply.

[biffrapper]

@negativeExponent Not sure, both munt and roland va work perfectly for libretro dos. No idea why instruments aren't initialized properly here, all instruments seem to play well other than being only pianos. Win10 64bit.

it would be helpful if you can post sound samples. im not entirely sure of what is suppose to be the correct initialization. but i dont hear pianos here. unless im using munt (mt32) for example, and use Standard in libretro api's midi interface and use GS/GM/SC-55 device in game config like Akumajou Dracula.

also helpful would be the synth used and its config its its other than default, including soundfont used. i myself turn off reverb and echo in my settings coz its just annoying to listen sometimes.

thanks for the reply.

@negativeExponent I have tested this two different ways:

#1: I am using a real, stock, first generation Roland SC-55 Sound Canvas, plugged into my PC via MIDI cables. This is a true external midi device as was sold in the 1990s on authentic hardware.

#2: I am using a Nuked SC-55 emulator, connected to the PC through loopMIDI, which creates a virtual MIDI port/device within Windows 10. For this I am using the SC-55 MKII BIOS ROMs.

In both cases, within PX68k core under options, I have selected:
MIDI Output: ON
MIDI Output Type: GS
ADPCM Volume: 15
OPM Volume: 12

Within Retroarch under Settings -> Audio I have selected (depending on whether I am using device #1 or #2:
Output: Windows MIDI Port
-or-
Output: loopMIDI Port

In either case the core is reaching the device. They are being initialized improperly, however, as described earlier, but sending a double init code through the MIDI signal--the first initializes GS, the second forces Piano mode, as Riggles pointed out:

""When sending MIDI PC (program change) messages to set the instruments, the core sends two PC messages for each channel. The first one has the correct value, but the second one is a 00 value that defaults to a piano sound. That's the reason why all instruments ends up sounding like pianos. With MIDI-OX you can log the core's MIDI output, and clearly see the issue.""

This is why the sound doesn't sound right. I am -not- using a soundfont. I am -not- using Windows MIDI device. We are using true devices, or, for all intents and purposes with #2, a true emulated device using the actual ROMs on the newly released Nuked-55 SC-55 emulator that was released on github in May. With #1 I am using real period hardware. Both work /flawlessly/ in DOSBox-Pure and DOSBox-Core within Retroarch. Those are both libretro cores.

FYI Type GS is required for Sharp 68000 games that use the SC-55. I can double confirm this by using the XM6 emulator, where this must be selected in that as well. In XM6 the sound is perfect, FYI. XM6 is not a libretro core. XM6 is a external emulator not part of Retroarch.

I can provide recordings if needed later today. For now, this is what Akumajou Dracula should sound like on a SC-55:

https://www.youtube.com/watch?v=sTIHT8nEA6s

[negativeExponent]

MIDI_Reset never gets called until core close. Try adding MIDI_Reset() at the end of MIDI_Init() in x68k/midi.c

UPDATE:
just tested with Nuke SC-55 as well, sounding right to me as far as not hearing pianos at init or restart. using SC-55 1.21 firmware

are you guys on windows?

[biffrapper]

@negativeExponent Yep I am on Windows 10 and have the same result on two different Windows machines.

[negativeExponent]

pushed a PR to fix this issue... at least as far as initializing instruments.
(tested with Nuke-SC55 + loopMIDI in a very very sloooow Windows 11 operating system.)
nuke sounded ok, but some effects are missing. munt is a total disaster. dunno if its my config but running windows on my systems is just really slow. see notes on pr.

[negativeExponent]

after testing on a very slow windows machine, i can say as far as getting instruments initialized, it would appear that on the px68k side at least, the PR i sent, specifically only sending 3 bytes of data in midi_out_short_msg() should be enough to fix it. BUT, it appears that the winmm driver differs from the alsa driver in retroarch, to be specific, munt may still not correctly initialize instruments, but general midi and SC-55 sounded fine other than missing bend/pitch effects. This pitch/bend issue can be resolve by changing just one variable in winmm_midi.c.

i've look at dosbox, and despite it using the libretro api for midi, it appears to be just handling minimal commands, and the sysex buffer and handling is dont elsewhere

see: https://github.com/libretro/dosbox-core/blob/27b6dbe8608ff63aaf8d5b7257a2b08c7d1a7a90/src/gui/midi.cpp#L131

in any case, heres a modified px68k with the modification s for windows 64bit users. maybe RA just dont like my windows PC so this may work differently on other machines. send feedback if you can. tnx

px68k_libretro_x86_64.zip

[biffrapper]

Getting closer! Had a few minutes to test and I noticed that the instruments were being held and not released, the longer the game ran. I was playing Akumajou Dracula, fyi. The pianos are gone and now instruments are initializing, but the pitch is sometimes off.

When I have some time later I'll post up a comparison video so you can hear. I have a pretty powerful machine so has the horsepower to stream and upload.

Thank you so much for everything you have tried so far!

[negativeExponent]

thanks for the test and feedback. can you test with this modified version of retroarch? it should sound better for SC55/GM... but somehow MT-32 messages are still getting dropped somewhere.

heres the link: https://www.mediafire.com/file/d7mwx55oaw8nite/retroarch_x86-64_plus_dll.zip/file
github only limits 25MB for upload so i have to send this files from somewhere else. just to be on the safe side incase these (free upload site does nasty things), here is the hash of the actual zip.

retroarch_x86-64_plus_dll.zip	MD5	4BB3E3F7599C1EFFAE1F5BFD77AA5919
retroarch_x86-64_plus_dll.zip	SHA-1	0593DCF857CA1C3B57E724688965CEB695D5178E
retroarch_x86-64_plus_dll.zip	SHA-256	7B236EA3BF0C0CB4D71DEBB0F13377DADC297AA0258D2C7CF63CDA066A9F9449
retroarch_x86-64_plus_dll.zip	SHA-512	4021AEF0A26E3925C60D275C4D717E7A068180AE04C19188C8C82E0230352C81458415AA13F3EE7D58AE2FC5D2B57E4F44D04744C73A659BE7E629F945E2D01B

and here is the hash for the retroarch.exe only:

retroarch.exe	MD5	78B98E76601DCE8EF0A8E09ED77CD920
retroarch.exe	SHA-1	E8D5E9BD1D06D06048AE216F184B75B5DFAE4172
retroarch.exe	SHA-256	39A951F48A74DB8EC439E0C58BF7709F666DEAA07919E77074ACAAA9B45EF033
retroarch.exe	SHA-512	EC623B229F0DF8D58C91A3BE5357A615F94F5D475EB9F3DD779A744F0F0F4BD5885E933D4ACD44E3475169B49AC2CFC7B8957F1747288C2541E1D1735A601B02

you will need to run this on a separate retroarch folder though as the DLL will not be compatible with the release version. Just make a copy of your current RetroArch folder somewhere, delete the retroarch.cfg (so it will create new on with path for this testing folder) then just overwrite all files with the contents of the zip.

im not in hurry for your test result, so just take your time.

btw, what message can you see on your midi device? are you able to see for example 266 bytes long sysex messages? from F0 - F7? i can make a core post the midi msg on realtime and you can probably see and compare if what core is trying to send is actually recieved in your device. thanks.

lastly if you are to compile stuff, this would make things easier coz i can just post a repo of the changes and you compile. but i dont mid building it myself.

thanks.

UPDATE:

heres a newer modified retroarch.exe file. just replace the exe on the zip above with this:
retroarch_x86-64_v2.zip

retroarch.exe hash:

retroarch.exe	MD5	239BAD2BE819E5C59234E2E47F850E06
retroarch.exe	SHA-1	95BDD08FA807E54132CAB427FAFC285A450221C7
retroarch.exe	SHA-256	CBCE19DEB84FFD7C4E03A35F4F91DAEF9CDAA1ED570C818E4A704C01D9177BE2
retroarch.exe	SHA-512	1C3C821B2AA6919F6C6927DAF3F82E9D8973E61814BAD1E6BDEBA9850A921C4AAE6708B636D1E51AD4136324DCC094E363560E3FE8BB6167B0A6FC34DFCA507A

and if you are able to see what midi msg your device actually recieves, here is the logs of the midi messages being sent. it does not however show the full sysex message but it just shows the length of the data. this log was from Akumajou dracula, from where you select MT-32 or CM-55 screen, upto where the into sound will end.

midi_msg_logs.zip

[negativeExponent]

@riggles1 @biffrapper midi should be fixed now. you need to update both px68k and retroarch.
other individual PRs like no reset for midi type change has also been merged.

others may follow depending on severity and/or my availablity of time.
im also waiting for that guy who was working on savestates to send his PR.

[biffrapper]

@negativeExponent You are a Wizard, Sir! You did it! The SC-55 sounds beautiful now!!!!! Thank you!!!!!!!!!!!!!!!!!!! When I get some more time I'll try and test with MUNT, too. This is a miracle. I never thought this would be possible. Finally I can play X68000 with MegaBezel goodness.

[negativeExponent]

thanks for the added info and tests and confirmation that it works now. it helped narrow down most of the issue to be an RA windows driver problem.

[riggles1]

Woo, can't wait to get back home and give this a whirl :0 awesome!