Thanks, sergm. I'll take a look at your update when time allows. 😀

There are three things to consider.
* /fmath directory isn't needed.
* fpow2 function in fmath.h is too MSVC specific. (assembly part) It does not compile here.
* Makefile.am needs to be refreshed for some compilers.

ykhwong wrote:

There are three things to consider. * /fmath directory isn't needed. * fpow2 function in fmath.h is too MSVC specific. (assembly […]
Show full quote

There are three things to consider.
* /fmath directory isn't needed.
* fpow2 function in fmath.h is too MSVC specific. (assembly part) It does not compile here.
* Makefile.am needs to be refreshed for some compilers.

Well, let me explain ... fmath.h was born in attempts to speed up those heavy math of CVS Munt code. It therefore include the fastest 2-based exponent and trigonometry i've ever made. But lately, i used LUT in generate_samples() for powf() computation, so there is no really need for this anymore... You can safely change it with this:
fpow2(x) = expf(0.69314718f * x)

It works, thanks for your detail explanation. It's good to start with the latest CVS code from MUNT.

Apart that it doesn't have the echo effect, it sounds weird in Police Quest 2. However, it seems faster and more stable.

ykhwong wrote:

It works, thanks for your detail explanation. It's good to start with the latest CVS code from MUNT.

Apart that it doesn't have the echo effect, it sounds weird in Police Quest 2. However, it seems faster and more stable.

Freeverb that current Munt uses for reverb does not tuned for 44.1 kHz sample rate, so echo is too weak. And when i set 22050 Hz reverb sounds really incorrect. So, we must do resampling in Direct Music driver or somewhat change freeverb parameters according to the current sample rate setting.

Instead, i use win32_app, it sounds better as sample rate is MT-32 native 32 kHz and its easier to use. Moreover, Direct Music is really deprecated technology...

As for emulation accuracy it needs to say that emulation model of Munt isn't precise. But of course we can work with CC's "Rubix Cube" to approach as closest as possible to the real thing's sound.

Further, I've planned to redesign some aspects of Munt, but for awhile ...

maybe you could contact candacow and ask for being taken on in the munt team. Branching off munt is fine, but directly working on it and furthering would be good as well 😀

Dominus wrote:

maybe you could contact candacow and ask for being taken on in the munt team. Branching off munt is fine, but directly working on it and furthering would be good as well 😀

Well, I'm afraid, the Munt team has no time for this anymore, see Canadacow's post on this topic. And KingGuppy is the Munt admin, not Canadacow. So, let's fill the project with some fresh blood 😉

Yes, I know they have no time for this anymore, that's why I'm suggesting you two join the team 😉
So if KingGuppy is the admin, try him for joining the munt project. But don't feel pressured 😉

So, another reason for branching Munt is changing its concept. I'm seriously aware, that with the Munt approach of simulating the h/w precise sound simply isn't possible, or just too complicated to realize. Munt sources are full of empirical constants and things that need to be checked... In my opinion, this is due to inconsistent emulation model.

To my mind, the main problem is still with sound volume of partials. Some of these are playing louder then needed, other are too weak and hardly hearable. May be this is because of wave fading after the filter. I even try to normalize the sample after the filter, which of course not in anyway the right.

If we really try to made Munt "more accurate" as this topic promises, we must fully understand what exactly we trying to emulate.

Munt team's concept of producing synth waves is based on subtractive synth model. Although, on the Net you can easily find statements that the h/w does NOT really have a filter. Let's review some:

1. Louisg writing on this very forum MT-32 filter and waveform generator

2. http://homepage.mac.com/synth_seal/html/mt32b.html also saying about this however not in detail.

3. Interesting thoughts on the problem is http://music.columbia.edu/pipermail/music-dsp … ary/068385.html about implementation of D-50 filter. MT-32 must have the same but simplified LA engine in it.

All of this does not gives any ideas on Munt development though. Only that the model is not quite correct. But we can change the model anyway to be more precise. So my considerations are:

- Of course, there is no any filter in the h/w, neither analog nor digital. Early Roland's models have analog filtering, but D-50 (and MT-32) are all-digital. And there is no h/w resources needed to implement proper filtering. Remember, it was 1987 and memory was really costly, that is why Roland not made D-50 pure sampler (ROMpler). The Munt CVS code provides about 7 Megs of IIR filter coefficients. Even early release incorporates table about 250 KB of data not counting of that wavecache. Real-time computing of the coefficients as well as implementation of FIR filter MT-32 h/w simply does not afford.

- Reading the UG of D-50 it can be seen that filtered wave is symmetrical on slopes. This can only be achieved using FIR (too slow for 1987) or by bi-directional IIR filter (process data buffer forward, and then reversed). Latter is also slow and memory hungry as said above.

- H/w strictly requirements lead to think of another synth’s WG implementation. It can be waveshaping, phase distortion or even wavetable synthesis.

- I don't think there is a some form of CZ’s phase distortion implemented. Moreover, this one is patented by Casio.

- When comparing waveshaping and wavetable synthesis I do not see any advantages of the former but simpler implementation of the latter.

So, concluding all the above, we can simply implement wavetable synthesis model with sampled (or resembled) waves of the h/w. Researching WG with 4-stage low-pass filter (according to D-50 UG) I've noticed that the shape of a waveform is mostly determined by the cutoff frequency to wave frequency ratio. This is exactly what the MT-32 cutoff points are.

Therefore, wavetable can consist of the waveshapes sampled (generated) at the mastertune frequency for various cutoff points (0..100). The size of that table can be 6400 samples for 64 frames per table row. For 16-samples it is only 12,800 bytes. And it can easily fit to microcontroller's memory. Playback further is done by pitch variation in the same way as for PCM samples.

As for the resonance, it is more likely implemented in CZ’s way by adding decaying sinusoid and varying amp levels of both signals when mixing. Firstly, and more precisely in terms of emulation, we can add the resonant point to the wavetable. It therefore grows up to 12,800 * 30 = 384,000 samples, but, hey, we are not deal with a microcontroller.

So, if Louisg is still interested, and he can produce the wavetable by sampling from the real thing, and we may analyze the results.

I’m looking forward to respond of the new Munt team as for now I do not have the real h/w to deal with (as Ykhwong also. May be this is the main reason we trying to make perfect the emu 😎 ).

My suggestion would be to open a topic called "Munt Reloaded - Development" in MT-32 General or MT-32 Development sub-forum so it gets more attention and doesn't get lost here with other DOSBox topics.

BTW, great work!

Done

2 Ykhwong

I've added a patch for emulation of signal fading below cutoff point. That corrects volume somewhat. You can use it for your DosBox SVN build.

By the way, the patch for DosBox can be slightly improved for better MIDI message timing. Now, the patch plays messages between DosBox mixer cycles, not when the message comes. It can be sometimes hearable as note delay for a moment.
Look to mt32emu_win32app.cpp for details on time-stamping messages in buffer and correct rendering of samples.

2 Ykhwong
If you incorporate the library into DOSBox, sample rate probably must be set to 32000 Hz default as sounds best and CVS code tuned for this.
Also I'm unsure about the parameter WGAMP (Amplitude of waveform generator). FIXME says its value is the amplitude possible whilst avoiding overdriven values immediately after filtering when playing back SQ3MT.MID. I've set it to "more digitally concerned" 16384. It determines ratio between amplitudes of PCM samples and synth WG sounds. It needs to be checked.

Yes, the other sample rates (except 16000 and 8000, ...) may negatively affect the precision of sounds, resulting some distortions. I remember that the latest CVS code of MUNT includes constant listening test values and gulikoza's munt code uses 41000hz that I used to have in my older builds.

I am not going to incorporate your library to my release right now. As mentioned above, I don't like that it still sounds weird in Police Quest 2. You may also have to check the following codes for properly playing instruments.
partial.cpp in ScummVM codebase

1				if (filtval > ((FILTERGRAN * 15) / 16))
2					filtval = ((FILTERGRAN * 15) / 16);

partial.cpp in your CVS code of MUNT

1 			if(freqsum >= (FILTERGRAN - 500.0))
2 				freqsum = (FILTERGRAN - 500.0f);

I applied your cutoff point change to ScummVM munt code in my test build. It's getting worse as it cuts trumpet playing in the same game (PQ2).

1			// This emulates signal fading below cutoff point
2			if (filtval < 128) {
3				sample *= fpow2(.125f * (filtval - 128));
4			}

We are challegend as we don't have real devices. Referencing part of Scumm munt code would help if necessary. What if you set the value of WGAMP to 12382?

I am busy for my mid term exam so will not be able to check this for a while.

AFAIK, Canadacow made principal changes in the filter code in 2009. In particular, now filter coefficients computed in freq range 0..16000 Hz (FILTERGRAN = 16000 in tables.h). The condition you mention checks for the maximum freq for which there are computed filter coefficients. Again, for sample rate of 32000 Hz higher frequencies will produce aliasing. As I found from tests, Munt's filter always resonate and thus produce resonance sinusoid on the cutoff freq. Agree, that the code is not clear in some places. It really lacks of comments and there is nothing like Munt project docs as well. We deal with very same glitches and quirks the Munt team already have.

As for the "cutoff damping" code, it's necessary only accompanied with sample normalization. Samples are float, and after normalization signal becomes as louder as before the filter. So I introduced this damping code.

Of course, I tried to revert the WGAMP back, but, alas, don't get the sound any closer to the real thing. Canadacow indeed made a very classic "Rubix cube" for us to train brains. Nevertheless, my thoughts are not changing: I'm working on wavetable sound engine for precise emulation of the thing.

P.S. In the PQ2 intro theme those high trumpets cause aliasing due to high pulse width values. Sample normalization there is anyway not applicable, I've introduced it in order to get louder some sounds that hard to hear. When turning off normalization it sounds more correct. Just comment out rows between
// Dynamic amplifier for sample normalization
and
// In case of overdriving prevent clicks
But in this case, some details disappeared and heard too weak. Most probably due to inconsistencies in the filter. It's hard to investigate the problem without the thing indeed...

Thanks, Ykhwong. I've finally got the point why those weak sounds appear. When I've thrown in a trash this noisy normalization stuff and applied as you suggest the fading code but reverse it this way:
// This amplifies signal fading near the cutoff point
if (filtval < (128 + 16)) {
sample *= fpow2(((128 + 16) - filtval) / 16);
}
it at last seems sounding right more or less.

P.S. After this change maximum amp must be lowered to prevent overdrives. Most hearable on Prince 2, I think. In tva.cpp I've set
amp = 40 + system->masterVol; // better correspond to volume changes

P.P.S. Found this one even more appropriate:
if (filtval < 128) {
sample *= .125f * ((128 + 8 ) - filtval);
}

ykhwong wrote:

<skip>

I am not going to incorporate your library to my release right now. As mentioned above, I don't like that it still sounds weird in Police Quest 2.

<skip>

Corrected. There was incorrect handling of pulsewidth parameter for sawtooth waves. Those SynBrasses sounds 1 octave upper then needed.

BTW, the current sources are moved to GitHub and can be found at:
https://github.com/munt/munt/tree/munt_reloaded_import

Hey guys, I have tried to use this emulator patch playing Star Wars - Tie Fighter. The music result is good, not so accurated as the MIDI, so if there's any improve that I can do, please let me know 😉
ykhwong, thanks for your work on it!

The result can be seen here: http://youtu.be/yh24y8nBiak

(This emulator allowed the capture tool to record the music gameplay, that didn't occur with MIDI)

I think star wars tie fighter was programmed in an era where games began to use general midi as native, and then "converted" to mt32 compatible music, so it is perfectly normal that your midi sounds more accurate.