VOGONS


Munt Reloaded - Development

Topic actions

Reply 881 of 965, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

Hi Serg,
A Greek user has reported that he cannot load ROM files. I have checked and the problem seems to be that the path where he tried to load the ROM files from contained Greek characters.
In Munt's code this part gives a MT32EMU_RC_FILE_NOT_FOUND error when any non-Latin 1 character is found in the path even if the code page (System locale) is set properly:

FileStream *fs = new FileStream;
if (fs->open(filename)) {
if (fs->getData() != NULL) {
rc = addROMFile(context, fs);
if (rc > 0) return rc;
} else {
rc = MT32EMU_RC_FILE_NOT_LOADED;
}
} else {
rc = MT32EMU_RC_FILE_NOT_FOUND;

The file stream eventually calls mbstowcs_s() function for multibyte to widechar conversion.
I have compiled Munt's library with VC++ 2005 and there seems to be a problem with VC++'s mbstowcs_s() function:
https://social.msdn.microsoft.com/Forums/wind … forum=vcgeneral
Here it is suggested that setlocale(LC_CTYPE, ""); should be called otherwise the mbstowcs_s() function will use the "C" locale. I do not know if it is a cross platform solution so any other solution is welcome (the suggested solution works anyway).
Thanks in advance.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 883 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Ah, I see. This seems to be a problem with old MS C runtime. I can reproduce it also with VC 2008. Anyway, I think it's better to fix it at the application level rather than hack the library and change global locale.

Reply 884 of 965, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie

It's only possible to fix it at the application level if the application itself uses the same C runtime as the library. Unfortunately it's not possible in my case since the host application does not use any C runtime (it is written in Delphi). So I think at least a compile time conditional switch would be necessary at the library level that defines whether the library should override the C locale or not.
(BTW I could reproduce this problem with Win32 Munt binary releases so it seems the Qt application is affected too.)
Thanks.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
VST Midi Driver Midi Mapper

Reply 885 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

OK, will test it thoroughly when built as a shared library. And yes, both mt32emu-qt and mt32emu-smf2wav Windows builds are affected but due to another reason (they rely on support of UTF-8 which MSVC never provided).

Reply 886 of 965, by 95DosBox

User metadata
Rank Member
Rank
Member

Sergm here is a Possible bug I noticed:

When running DOSBOX with Munt (mt32emu-qt.exe) not loaded and not loaded minimized, then after starting the DOSBOX game with MT-32 support, then loading the Munt console (mt32emu-qt.exe), the console screen does not show the DOSBOX using Munt as a Synth X tab and thus no Synth green led status panel is available to see the effects MIDI messages.

Could Munt (mt32emu-qt.exe) autodetect when loading that previously engaged Munt synths check and show those Synth tabs? Or a Refresh Synth tabs button to update if they aren't showing up when Munt (mt32emu-qt.exe) was loaded after DOSBOX was running Munt detected games?

For example if you had say DOSBOX1: Wing Commander MT-32 running and DOSBOX2 Police Quest 3 MT-32 running. The games don't matter as long as the two DOSBOX programs are both tying up and using Munt.

If you opened up Munt (mt32emu-qt.exe) after you would see no Synth tabs present. There should be Synth 1 and Synth 2 tabs and if you were to play a MIDI file in the console it should be recognized as a Synth3 tab since the two DOSBOX sessions running Munt are and should be using the Synth 1 and Synth 2 tabs.

This isn't a major bug but just annoying but I would like to see the Windows 98 Port of Munt v2.2 done first if this bug fix will take a while to correct.

Reply 887 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

95DosBox

This behaviour was deliberately chosen. The Windows MIDI driver only detects if the Qt app is running when the consumer application opens the MIDI port. It does not search actively for the Qt app when its internal synth engine is already opened. The main reason why is that the state of the internal synth is tricky to transfer to the external app reliably. For example, you may start a game inside DOSBox. The game most likely loads its specific SysExes upon launch. Then you decided to look at the LCD, so you start mt32emu-qt. If the MIDI driver detected that and switched to the external synth engine, it would start playing just like after a reset.

When planning, we considered such possible problems and decided to make the synth engine only incorporated into the GUI-based application for simplicity. We do not run a synth core service that may be shared among several applications or run in background. Neither we want to transfer any internal data from a synth engine to a GUI app like we did before (I mean that external interface existed in versions prior 1.0). Although, on Windows platform, the MIDI driver is a must, and after some thought it was allowed to be stand-alone and have an internal synth engine.

This means, the plan is to keep mt32emu-qt running in the system tray if you need it, or simply use the MIDI driver if not. Nevertheless, there is a simple way to connect a running DOSbox to a freshly (re-)started mt32emu-qt. Whenever you open the mt32emu MIDI port, the driver attempts to find the Qt app and connect. This can be done e.g. by issuing command "mididevice win32".

Reply 888 of 965, by Cloudschatze

User metadata
Rank Oldbie
Rank
Oldbie

NewRisingSun brought an issue to my attention that would appear to be a bug, or at least an off-behavior, in some portion of the Munt code. Namely, when two or more Parts are set to receive on the same MIDI channel, only the lowest-numbered Part will actually produce sound - the other applicable Parts remain silent, and register no MIDI activity whatsoever (via the emulated LCD). This incorrect behavior does not occur with an actual MT-32 or CM-variant.

Reply 889 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Thanks, Cloudschatze

This reminds me the issue with Death Track we have in early times described in this post. After that, we changed the part mapping so that the first part wins if more than one is assigned. Previously, the part with the highest number won. Not really sure whether any of these ways is correct though, I'll double-check.

Reply 892 of 965, by Myloch

User metadata
Rank Oldbie
Rank
Oldbie

any of you programmers volunteer to fix munt implementation in dosbox-x?

Latest dosbox-x builds: selecting mt32 output, even with mt32 roms, sound output is broken/crap. It used to work in the past.

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Reply 893 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++
Myloch wrote:

any of you programmers volunteer to fix munt implementation in dosbox-x?

Latest dosbox-x builds: selecting mt32 output, even with mt32 roms, sound output is broken/crap. It used to work in the past.

Why not just install the Windows MIDI driver version of Munt, and then point DOSBox at that?

Reply 894 of 965, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

That would be the easiest solution.
Other way would need you to get a develope environment up and do a git bisect to get to the point at which the git of DOSBox-x fails

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 895 of 965, by Myloch

User metadata
Rank Oldbie
Rank
Oldbie

I would have preferred to avoid installing 2 other programs or drivers that stay in memory (I already use virtualmidisynth) but I tried installing munt and a midimapper and mt32 emulation works very well with latest dosbox-x builds (default midi output). And it's a bit more accurate than how emulation used to be in the last ykhwong build and other working older dosbox versions with mt32 internal support. I wonder how the impact is (performance-wise).

"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"

Reply 896 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

I don't think Munt is a memory hog. The ROMs are small. It's nothing like the memory usage required for soundfonts.

I also doubt there's a performance penalty or even noticeable lag, since MIDI was a thing in Windows at least as far back as 3.1.

Reply 897 of 965, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

The munt midi driver is the newest build with many improvements. Ykhwong's build is ancient by now and DOSBox-x might have still used that code instead of the DOSBox patch provided by Munt

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 898 of 965, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++
Myloch wrote:

I would have preferred to avoid installing 2 other programs or drivers that stay in memory (I already use virtualmidisynth) but I tried installing munt and a midimapper and mt32 emulation works very well with latest dosbox-x builds (default midi output). And it's a bit more accurate than how emulation used to be in the last ykhwong build and other working older dosbox versions with mt32 internal support. I wonder how the impact is (performance-wise).

The last time I tested on my netbook, Munt loaded the Atom N270 to about 70%, so the CPU usage is significant. However, it really shouldn't matter for any multi core systems running DOSBox, and you can also run it off board on another computer when using older single core machines for DOSBox or native gaming.

All hail the Great Capacitor Brand Finder

Reply 899 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

For performance I was comparing embedded Munt to driver Munt. The performance of the MT-32/CM-32 emulation core shouldn't be appreciably different, and may even be effectively better with the driver version because it could be more likely to run on a separate CPU core.