So, after long awhile, the Munt Project has been revived.

And the main reason for this is finding alternative concepts in order to get more precise emulation of the famous hardware module.

Taking a look to the work completed by the Munt team, one may come to conclusion that it’s hardly possible to achieve for the emu exactly the same sounding as the hardware. We plan to change things some way.

The main target to improve is the wave generation and filtering algorithms. There are number of things to be checked:

* Is the shape of the waveform really depends on the pitch.
* How exactly resonant points influence the waveform. Is the resonance value 0 means no resonance at all. Just found that Munt generates resonant waves for ANY values.
* How waveshape depend of the pulse width.
* How changes volume of the signal when varying cutoff and resonance points.

The only way for finding answers is getting sampled data of the hardware using predefined SysEx-s for a single partial instruments. And the reverb of course is the last thing to deal with.

UPD: There is no difference in the signal in Munt when changing resonance in the range 0..10. Strangely...

*EDT* This is because of formula
resonance factor = 1 + (resonance / 30)^5
and thus resonance values below 10 are less then 0.01 and rather no matter...

I have one test case where munt still fails: The intro of Ultima 7 - The Black Gate. At http://dl.dropbox.com/u/7737184/Ultima7intro.zip is a real MT32 recording of the intro. It's three parts, the middle part is ok with munt (to compare I used a built of Exult with yhkwong's recent changes and an SVN built of Dosbox with yhkwongs changes). The problem is especially with the first part, the birds chirping. With munt you only hear some kind of effect when you turn the volume very high and even then it is not the correct one. The third part (that's when the Guardian appears on the blue static screen in the intro) might be almost correct now, too.
When you run U7, make sure to disable sound effects in the installer so you can correctly compare it.

Dominus, the Munt codebase you've tested is not related with the project in subj. Probably you use Ykhwong's DOSBox build Feb. 19. 2011. It incorporates ScummVM codebase of Munt. I've started Munt Reloaded Feb. 23 2011 based on Munt CVS codebase which rather different and improved, and thus results of your test can hardly be used with this.
Again, the project is in a very start stage to make a comparison by whole tunes. We need to investigate at the lowest possible level - partials, first.
And thanks for paying attention on our efforts, may be you can help with the reverse engineering as well.

ok, good luck with it then, just keep this in mind when you want to compare stuff. as you've written you have no real device.

Dominus wrote:

ok, good luck with it then, just keep this in mind when you want to compare stuff. as you've written you have no real device.

Year... the hardware in my hands would speed the things up greatly...
But, hey, this is TEAM work, so it may be even better though...

After performing several tests on Munt I've found that:

1. Implementation of resonance values below 10 rather irrelevant. According to the D-50 docs 0 resonance produces waves without the resonance peak. Also, for high resonance values docs say that the signal itself fades, but resonance peaks grow. There is nothing like that implemented in Munt.

2. The waveform really does not depends on the pitch, but the resonance peak. If it's emulated separately, the wavetable concept for cutoff values above 50 is quite correct. Cutoff values below 50 (approx 56) are simply fading sinusoid of the same shape thus there is no need to place it into the wavetable separately.

3. For extreme pulse width values, there is sensible loss of wave loudness. This corresponds to the low-pass filter model, but who knows what the real thing do. Also, for high pitch values, there is audible aliasing as the pulse width becomes below the half of the sample period.

4. As I've already mentioned, Munt's filter always resonate. Such a behavior does not correspond the low-pass filter model in terms of irrelevant resonant peak for frequencies around the cutoff point (cutoff values 50-60). But it is unknown how signal level changes on the real hardware.

So, the concept of wavetable algorithm for WG+filter emulation is quite adequate. Funny, but the Munt is trying to emulate using real filter behavior of the hardware, that itself emulates real filter work. 😕 This is really confusing... Anyway, we can start updating the sound generation engine and fill the wavetable with the current filter behavior, then correct it as needed.

These things are to be checked on the real hardware for being consistent.
Can anybody participate in the research and provide information about the real thing working? 😀

I am amazed by the low CPU usage of win32app when used (through MIDI Yoke) with DOSBox even when upping MT32EMU_MAX_PARTIALS and MT32EMU_MAX_POLY to 128 as I was getting no free partials error while playing Dune 2. Music sounds good most of the time but sometimes there is some noise like when sound is too loud but it isn't. I'll try to record offending music parts.

Edit:
Here is part from intro music in Frontier: Elite 2 (available as shareware download on the internet). You can hear the noise most noticeably in the middle of the part.

Thanks for testings, Miki. This overdrive you observed most likely due to uncertainties of the max amplitude. Original Munt CVS stated that max amp = 155 (see tva.cpp) then master volume was subtracted transformed through a table. KG says this corresponds LAPC-I behavior and very different on MT-32. So I change this to amp = 55 + system->masterVol. 55 must therefore be reduced to avoid overdrives. Besides, AFAIK, MT-32 itself can be easily overdriven also.

0.9.2 released. It incorporates last changes in source as well as slightly lowered maximum volume to prevent overdrives. If overdrives ever experienced, it can helps just lowering master volume via the Front Panel interface. Just like for the real MT-32.
It is not recommended to use DirectMusic driver. Munt code seems to be bound to 32000 Hz sample rate (that is native for MT-32). The driver can produce sound only for standard sample rates, e.g. 22050 and 44100 Hz and sounds really different and inconsistent. Please, use win32app instead for the best experience and simplicity. Besides, DirectMusic is deprecated and the driver cannot also be compiled easily.

If anyone is looking for a link to the project page, here it is:
http://sourceforge.net/projects/muntreloaded/

Any way to incorporate this into dosbox? Otherwise I can't test it since I'm on OS X. Or is it supposed to be a Windows only thing?

Think Ykhwong is working on it... The library mt32emu doesn't differ on its program interface. And ALSA driver should also work with it.

Dominus, this is sergm's munt reloaded patch for the latest SVN of DOSBox.

Changes
* fmath.h can handle both MSVC and GCC.
* Disabled every logging message.

Thanks, I'llcheck it out this night (cet).

I think your current analysis is dead on regarding the resonant filter. The filter component seemed to be the hardest part to simulate accurately when all other parameters have been controlled for.

Let me know if there is anything I can do to help!

EDIT: Listening to the changes that have been made so far and it sounds AWESOME! Good work!

It is great hearing from you, Canadacow, that you still ready to help in our attempts of making Munt better. It would be surely an advantage if you could share the results of reverse engineering the Team has already performed. It’s obvious, people who want the emu sounds correct the most do not have the hardware.
As you surely know, the filter is a toughest problem in solving this Rubix Cube. I've thought of two possible reasons but without the real hardware the analysis is surely dead 🙁
If only KingGuppy could help in the research with use of his digital sampling hardware…

For the current filter model I’ve found no faults except the next two.
1. Very probably irrelevant filter resonating for resonance values in the range 0..10. This leads to inappropriate signal loudness around the cutoff point (cutoff 50). As known, at the cutoff frequency, the filter attenuates the input power by half or 3 dB. I suspect Canadacow has left the filter resonating to make it in accordance with MT-32 behavior in terms of signal volume.
2. It seems that below the cutoff point the filter stops resonating and the volume of signal fades much faster then on the real hardware.
I don’t think it is necessary to do something with the first this far. But the second one must be confronted as for this the partials with cutoff below 50 are over-attenuated by the filter and thus barely hearable.
Concluding the above said, it can be stated that the filter model implemented in Munt is a true resonance IIR filter. And as opposed to this, MT-32 seems to emulate real filter behavior with some flaws. So, for exact modeling the hardware it’s needed to hack the filter in Munt to made it to behave corresponding this MT-32 emulation.