Hmm, why so? It works almost perfectly... on Windows 98. You just need to install that OK, there is only one notable thing worth to mention that version 2.2.0 is missing and I'm on cleaning things up. Likely do a release since I completely out of time these damn days

HunterZ wrote: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.

Just to clarify, the DOSBox patch started to support rendering in a thread (enabled via "mt32.thread on"), so this is kinda obsolete info But you guys are right, there is no noticeable difference in performance of DOSBox+MT-32 vs. DOSBox+mt32emu_win32drv. In a Windows NT environment, there is even no context switches when DOSBox transmits a message to the driver, it's like a usual DLL running in the context of user process. In Windows 9x, this is far not so simple, though.

Another matter is that integrated mt32emu engine is far more convenient than dealing with MIDI arch in modern Windows...

Normal way of MIDI driver installation seems to work more reliably than the way used with the driver setup. Unfortunately, this way requires driver signing for x64 arch, despite it is a userland driver, so it's kinda weird for me why. Nevertheless, the registry hack used to install the driver is incomplete and Windows often overrides it. Not too convenient. Perhaps, I'll end up adding a MIDI driver checker that will run e.g. using task scheduler and restore things to work.

As for the argument "I don't want to start a program...". Well, there is no need to start a program if it is started automatically. One can simply put a shortcut to mt32emu-qt to the startup folder and viola. Besides, there is no need to start a program if it is unnecessary.

sergm wrote:Normal way of MIDI driver installation seems to work more reliably than the way used with the driver setup. Unfortunately, this way requires driver signing for x64 arch, despite it is a userland driver, so it's kinda weird for me why. Nevertheless, the registry hack used to install the driver is incomplete and Windows often overrides it. Not too convenient. Perhaps, I'll end up adding a MIDI driver checker that will run e.g. using task scheduler and restore things to work.

Ah, that explains a lot.

I wonder what the CoolSoft stuff (VirtualMIDISynth, MIDIMapper) does, and whether it's more resilient than Munt?

Yeah, Coolsoft stuff is really cool. Sadly, it's hard for me to find time to hack Windows internals as deep as they did, and I didn't success in finding the sources, so that munt would also benefit from using these techniques

sergm wrote:Perhaps, we should really be providing an "official" DOSBox build patched with mt32emu but again, if only I was cloned

Probably the ideal solution would be for DOSBox the be enhanced to support .dll/.so based MIDI driver backends, so that you could produce precompiled Munt drivers that could be plugged into DOSBox without rebuilding DOSBox.

Never tried the ECE builds, but as far as I remember the coolsoft guy is a forumer here and maybe he agrees to give ya some advices.

Munt bug(?): I noticed some (subtle) static sounds during level 1 music in prehistorik in latest munt compared to this. I use all munt default settings (except for dac: generation 1) and mt32/blueridge roms. Hard to explain but you can easily catch and test the game out there

Game bug(?): in colonel bequest: rumble sound outside, near the fountain gate is audible only if you lower ingame speed to low values. Same for the mansion chandelier, except the sound is not mute but it truncates and loops repeatedly.

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

Note, that prehistorik has limited MT-32 support (as well as SB support - this is a rare game that relies on the Creative SB driver ). It neither defines custom patches nor even sends SysEx messages. Thus, be sure to reset the synth manually in advance.

Also, it does suffer from the digital overflow problem when using new-gen devices. For instance, I can hear slight cracklings with CM-64 (very similar to the performance of mt32emu in the DAC Emulation mode "Generation 2").

The CM-32P part uses a wholly different synthesis engine. You basically have to start from scratch to emulate it. It may seem simpler being just a ROMpler, but will be just as difficult as a Sound Canvas if you want the emulation to be accurate.

Moreover, you need to start with the dumps of the built-in CM-32P Sample ROM and Control ROM and build out with the expansion cards. While the Sample ROM and Control ROM may be easy enough to dump, dumping the cards is going to be a tad more challenging. The CM-32P can shape the output of the samples to some extent and it also has a reverb unit.