VOGONS


Munt Reloaded - Development

Topic actions

Reply 20 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

After thorough testing, it’s clearly no more need in sample normalization. It’ll be removed in 0.9.3-release. Instead, there is a hack for amplifying the signal after the filter. It sounds really good and doesn't introduce noises for highest pitches as sample normalization did. I've decided to keep the maximum volume as the Munt CVS suggests since there is no way to make it higher but one can easily make it lower using the volume knob to avoid overdrives. I found strongest overdrives playing Prince 2 but after lowering volume down to 84 overdrives are not appear.

Reply 21 of 964, by canadacow

User metadata
Rank Member
Rank
Member

You are completely correct about my implementation of the filter below values of 50. A good example of the mismatch with the filter and volume is the whistle that plays during the prologue of Space Quest 3.

Given what you've been saying, it is my thought that at or below an absolute cutoff of 50, the MT-32 is doing little more than using a sine function at a particular volume, where as MUNT actually filters the remaining sinc partial away.

Does this make sense?

Reply 22 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Thanks again, Canadacow, for responding and participating in the discussion. Sadly, but it seems that nobody else is willing / able to help with detailed analysis of hardware behavior.

But I really have a hypothesis on explanation of MT-32 “pointless” behavior in terms of hardware realization for those microcontrollers and corresponding hardware requirements. I’ve already posted my considerations to Ykhwong’s topic “More accurate MUNT (MT32 emulation) patch” and now repost it here for correctness.

I really do not want to make endless hacks in MUNT. I doubt that this way leads us anywhere. Let’s try to examine details of MT-32 behavior in aspects of how it can be realized in hardware. Maybe using brainstorm way. I believe using of corresponding model for hardware emulation is essential to achieve pretty good results.

Reply 23 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

<skip>

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 is NOT really has 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.

<skip>

Reply 24 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

What it's really needed is build up the model that can be realized in MT-32 hardware. As I understand, KingGuppy isn't succeeded in disassembling the software of the MT-32 microcontrollers. So, I propose to make hypothesis, compare and use the most relevant to what we observe in reality.

Another thought. There is an advantage of using wavetable synth engine in its ability to sound exactly the voice of the hardware replaying all nuances and flaws of the hardware. Maybe this is the easiest way of producing vintage sound exactly. Really, there is no need to use original PCM ROMs that let the emu sound exact if the synth partials are sound only as a rough approximation.

Do you think we really can manage it?

Reply 25 of 964, by canadacow

User metadata
Rank Member
Rank
Member

I agree with everything you've described here. Even with a square wave generator, those can be made by subtracting sawtooth points given a particular pulse width. The mystery remains, however, where did those samples come from to start? They aren't found on any of the ROMs.

Not sure what you mean by not needing the PCM ROM. Those samples are pretty unique to the MT-32 and I even took Roland on in challenging their copyright. Last time I checked they were unable to support their claim to copyright so for the time being we're under their radar.

Not sure where to go from here. I'm most fascinated by the filtered waveform generation using wavetable synthesis. This sounds to be the most promising path.

Reply 26 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

I’m grateful for your attention, Canadacow, and really hope that we could achieve some respectable results in our efforts if you could only have time for this…

As mentioned before, I believe they made the wavetable so small (e.g. 12,800 bytes) that it silently sits in the microcontroller’s memory, not in separate ROM. Again, wavetable can be shrunk down to 6,400 bytes since for cutoff values below 50 there is no changes in the shape of waves, only in amplitude. This is for square waves, and for producing sawtooth waves as you know they easily can use cosine wave from that table for cutoff 50. MT-32’s crystal-clear and unique sounding convinced me in a thought of using wavetable, not waveshaping or something else. Although, thorough analysis must to be done to approve anything that could be stated. Most probably filtered waves constructed by using FIR filter. This explains their symmetric and clearness.

As you probably notice, English isn’t my native language, so I’m ready to be misunderstood sometimes. When saying about not using the original ROMs I mean there is no benefit of the ROMs when the emu still sound not exact. We can reconstruct attacks and loops similarly to the original ROM data using free patches and the sound quality will still be imperfect. Of course in such a case it’ll never be exact.

I’ve already read up with your challenge against Roland in order to confirm the possibility to provide their ROMs with your project. I think they refused because they still make money on their famous LA synthesis, see http://www.roland.com/products/en/VC-1/.

I’m amazed of that OPLx decapsulated reverse engineering report https://docs.google.com/Doc?id=dd8kqn9f_13cqjkf4gp. If we could afford such level of inner design information of LA chips, making the exact emu is trivial. But for now I propose to start form filling the wavetable with square wave samples (preferably digital) from the hardware on freq 500 Hz (there will be exact 64 samples long for a period) varying in the full range cutoff (0..100) and resonance (0..30). There will be 3000 rows and it’s surely needed a method of automation for the sampling process to accomplish.

Looking forward to hearing your opinion.

Reply 27 of 964, by ponytear

User metadata
Rank Newbie
Rank
Newbie

Hello,

I just tried the new Munt Reloaded and I wanted to say a huge thank you!!! 😀

I am a huge Legend of Kyrandia fan and the old Munt was not working well with it, playing some instruments out of tune. But the new version works beautifully, it's amazing! It's not exactly the same as the real MT-32, but I love it just the same. There is just a little too much reverb, I think, but that's not really important.

I have tried it with DOSBox and ScummVM and it works great! Thanks a lot! 😀

Reply 28 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
ponytear wrote:
Hello, […]
Show full quote

Hello,

I just tried the new Munt Reloaded and I wanted to say a huge thank you!!! 😀

I am a huge Legend of Kyrandia fan and the old Munt was not working well with it, playing some instruments out of tune. But the new version works beautifully, it's amazing! It's not exactly the same as the real MT-32, but I love it just the same. There is just a little too much reverb, I think, but that's not really important.

I have tried it with DOSBox and ScummVM and it works great! Thanks a lot! 😀

It's very nice to hear that you enjoyed our work. I didn't really understand reasons why KingGuppy and Canadacow just abandon such a promising project after so huge and hard work they've done in 2009 making current Munt almost perfect. 😳

And of course Munt doesn't sound the same as the your favorite music module but here we're just working on it. I really want to see (and hear) the Munt Complete which sounds exactly as that Roland's toy.

As for reverb tunings, I haven't worked with it enough to make properly. I just think it isn't the major task for now. You'll notice the reverb grows with sample rate going down and vice versa. Maybe Canadacow can say what exactly the sample rate is intended for the current reverb tuning.

Reply 29 of 964, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

@yhkwong: your patch is missing the integration into Dosbox, from your previous munt patch, the midi_mt32.h file. I tried using one from your patches but didn't succeed 🙁

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 30 of 964, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote:

@yhkwong: your patch is missing the integration into Dosbox, from your previous munt patch, the midi_mt32.h file. I tried using one from your patches but didn't succeed 🙁

Sorry about that I missed midi_mt32.h.

Attachments

  • Filename
    mt32emu_0.9.3_dosbox.diff
    File size
    234.98 KiB
    Downloads
    33 downloads
    File license
    Fair use/fair dealing exception

Reply 31 of 964, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Thanks, the patch is still missing the integration (changes to dosbox.ccp and midi.cpp) but I managed to do that manually at least (again following what you patched in the old patches) 😀

Still wrong sfx for bird chirping with this but it's much more audible now 😀

Reply 32 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Ykhwong:
As for integrating MUNT into DOSBox maybe the way of plug-in loading is better. At least a patch for using precompiled library I think...

Dominus:
You can vary loudness of missing sounds by changing MAGIC_NUMBER in partial.cpp generate_samples():

// This amplifies signal fading near the cutoff point
if (filtval < 128) {
sample *= 1.f + (128 - filtval) / MAGIC_NUMBER;
}
which amplifies the wave after the filter as pleasant to your ears 😀

Reply 33 of 964, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote:

As for integrating MUNT into DOSBox maybe the way of plug-in loading is better. At least a patch for using precompiled library I think...

I remember I used to have it as a static library about 3 years ago, but that often makes me hard to maintain or customize. 😀

Reply 34 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
ykhwong wrote:

I remember I used to have it as a static library about 3 years ago, but that often makes me hard to maintain or customize. 😀

Of course this is an Open Source project and everyone can prefer his own way of use it, but I think encapsulation is a great thing too. As for me, mixing Munt sources into "gui" dir do not simplify maintenance. KingGuppy even use the stand-alone MUNT library for his DM driver and for ALSA driver, and for SMF2WAV etc. I don't believe this way complicates working with MUNT but surely encapsulates the project as self-contained, IMHO.

Reply 36 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
gulikoza wrote:

I had this on my TODO list for a while now...changing DOSBox patch so it could have Munt in separate dir... 😀

It's great, Gulikoza. BTW, maybe there is a need to enqueue timestamped MIDI messages in the buffer in order to render them in time. I've noticed a minor desynchronization listening tunes in your DOSBox build and through the MIDI driver. Could you tell how long (in milliseconds or samples) is the delay between Synth::render() calls?

Reply 37 of 964, by gulikoza

User metadata
Rank Oldbie
Rank
Oldbie

No idea actually...the worker thread just renders as fast as possible, but I guess some delay could occur because it is rendered asynchronously. Either that or the whole emulation pauses before the samples are done 😜

http://www.si-gamer.net/gulikoza

Reply 38 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Yes, maybe because of not much speed of MUNT.

P.S. I've also noticed, DOSBox eats significantly more CPU than DM driver I've built on MUNT CVS code. I suppose this is due to more overhead in calls to render(). DM driver calls render() in between of playmsg() calls and use timestamping to preserve accuracy of playback. 😎

Reply 39 of 964, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
canadacow wrote:

I agree with everything you've described here. Even with a square wave generator, those can be made by subtracting sawtooth points given a particular pulse width. The mystery remains, however, where did those samples come from to start? They aren't found on any of the ROMs.

<skip>

Oops, the microcontroller in MT-32 is Intel's C8095-90 or P8098 and they both are ROMless. If it's true the wavetable must be in one of the ROMs or may be generated in run-time. I still don't believe Roland use waveshaping or phase distortion but who knows. The Control ROM must contain all the software the microcontroller runs, is it right?

P.S. There is definitely no time for computing digital filter. The latency of mul / div operations is 6.25 microseconds and there must be processed 32 x 32,000 = 1,024,000 samples per second. How can they afford it?