VOGONS


Munt Reloaded - Development

Topic actions

Reply 900 of 965, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Yeah, I suspect a 31250 baud bus in software is nothing compared to the synthesizer core.

All hail the Great Capacitor Brand Finder

Reply 901 of 965, by Myloch

User metadata
Rank Oldbie
Rank
Oldbie

I cannot install latest munt drv (snapshot) from 1st october, I use standard 2.2.0 version. How am I supposed to update driver?
I feel stupid.

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

Reply 902 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
Myloch wrote:

I cannot install latest munt drv (snapshot) from 1st october, I use standard 2.2.0 version. How am I supposed to update driver?
I feel stupid.

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 🙁

Reply 903 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
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.

Reply 904 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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. 🤣

Reply 905 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++
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?

Reply 906 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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 😀

Reply 907 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
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.

Myloch, what do you think about DOSBox ECE (Enhanced Community Edition) builds? IIRC, YesterPlay80 pays attention on both mt32emu engine and the DOSBox patch updates, so I believe his solution is recent enough.

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

Reply 908 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++
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.

Reply 911 of 965, by Myloch

User metadata
Rank Oldbie
Rank
Oldbie

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"

Reply 912 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

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").

Reply 913 of 965, by Myloch

User metadata
Rank Oldbie
Rank
Oldbie

Minor suggestion would be to add a hide button in the munt control panel itself.

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

Reply 914 of 965, by a0divided

User metadata
Rank Newbie
Rank
Newbie

There seems to be a problem with the "Engl Horn" patch sounding quite distorted on lower notes at high velocities, here's a previous post with longer explanation:

Munt - distorted patch sound?

Reply 916 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++
SLON wrote:

What I have long wanted to ask... Will there ever be support of CM-64?

The only difference between CM-64 and CM-32L is that the CM-64 also includes CM-32P functionality, which is not used by any games as far as I know.

Reply 918 of 965, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

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.

Reply 919 of 965, by Great Hierophant

User metadata
Rank l33t
Rank
l33t

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.

http://nerdlypleasures.blogspot.com/ - Nerdly Pleasures - My Retro Gaming, Computing & Tech Blog