If anyone experiences problems with the latest build, please, let me know...

Hi Sergey & Jerome,

Munt has become fantastic since the first time it was developed around 2003. You have done an immense job lately. Most of what I have listened to sounds spot on.

The only real bug I have encountered so far is during the playback of Conquest of the Longbow. In the complete MIDI soundtrack recorded by Quest Studios, the tune starting around 17:10 ("The Widow") has awful suspended notes with Munt but not with my CM-64 nor with my CM-500.

I don't know if the bug is in Munt or if the MIDI file is actually malformed, but it's interesting that it will play correctly on a real synth and not in Munt. For info, I have tried with VanBasco and a few other players, and the result is the same.

o Quest Studios Complete MIDI Soundtracks
o Conquest of the Longbow Complete MIDI Soundtrack (direct link)

Kaminari Redux wrote:

In the complete MIDI soundtrack recorded by Quest Studios, the tune starting around 17:10 ("The Widow") has awful suspended notes with Munt but not with my CM-64 nor with my CM-500.

MUNT emulates CM-32L/MT-32, not CM-64/CM-500. CM-64 plays MIDI channels 11-16 used by CM-32P but the channels are not played by CM-32L.

I know this, but this has nothing to do with the issue. I'm not talking about additional channels here. The problem I describe is about suspended notes in Munt which continue to play when they actually should not.

One can easily reproduce and hear the problematic notes in Munt by listening to the file I mentioned in my previous post.

Hi, Kaminari!

Thanks, interesting one!

I found "The Shooting Glade" left the sustain pedal on:

Timestamp in port status data1 data2 chan note event
...
316315 1 4 181 64 0 6 --- CC: Pedal (Sustain)
316538 1 4 181 64 55 6 --- CC: Pedal (Sustain)
316551 1 4 181 64 114 6 --- CC: Pedal (Sustain)
316566 1 4 181 64 127 6 --- CC: Pedal (Sustain)

then in "Nottinghamshire (Map)" the 6th channel isn't used at all, and then in "The Widow" you hear sustaining RecorderMS patch since the pedal is still on.

Timestamp in port status data1 data2 chan note event
406472 1 4 197 10 --- 6 --- PC: RecorderMS
406476 1 4 149 89 115 6 F 6 Note On
407057 1 4 133 89 64 6 F 6 Note Off
407132 1 4 149 84 104 6 C 6 Note On
407691 1 4 133 84 64 6 C 6 Note Off
...

So, the pedal on the real device must be reset in-between...
There is no any Sysex'es during playing, only the following can be seen:

Play msg on unreg chan 0 (-1): code=0xb, vel=64
Rhythm: Pointlessly setting pan (44) on rhythm part
Rhythm: Attempt to set program (0) on rhythm is invalid

Maybe this leads to resetting the pedal? 😒

I suspect the sustain pedal (or even more control) is reset on program change.

Seems that it's alright now 😀

Works great, thank you! 😀

I'm not too familiar with the controllers supported by the MT-32, but most synths I know reset controllers like sustain or pitch bend during a program change (as a default behaviour, that is).

Alas, not the soft synths I know. Both M$ DMusic synth, Yamaha's S-YXG50 and Roland's VSC fail on this tune 😀

According to information from Mok, the MT-32 has these controllers:

• Modulation depth
• Expression
• Pitch bend
• Pitch bender range*
• Volume*
• Pan pot*
• Hold**

* Part of the "patch", so changed to the value in the new patch on program change.
** Explicitly reset on program change (this is the bit we were missing in our code, and recently fixed).
Modulation depth, expression and pitch bend are not altered on program change.

I have another bug to report with the complete soundtrack of Colonel Bequest.

At around 08:15, there's a small organ theme which starts with a thunder patch. In Munt, the patch is heavily distorted, saturating the rest of the music for a few seconds. In the console, Munt complaints about insufficient free partials for that patch.

Here are two recordings (turn the volume down!):

o LauraBow_CM64
o LauraBow_Munt

For info, I didn't change Munt's settings (replay gain is 100).

[Edit: updated the links.]

What is the status of the die analysis for the MT-32 chips?
Is it still a required step for achieving 100% accuracy?
And what areas in the emulation still need work?

It seems to me that now that the emulation is so close to the 100% mark, progress is slowing down, but I hope you won't lose interest.
Anyway - even at its current state - the emulation is top-notch. Thank you guys.

EDIT:
I see now that you're both very active working on the "mt32emu-qt" branch, so ignore what I said about progress slowing down. I was simply only following the "master" branch until now.

Hi OmerMor,

Regarding the die scans: Apparently the guys involved haven't given up or forgotten about it - I still get occasional "in progress" updates from them.

SergM did some incredible analysis work on the waveform generation that allowed us to get very close to what the LA-32 is doing. Die scans of the LA-32 would still be great to get 100% accuracy there, but it's far less urgent than it once was.

Die scans of the reverb chip are more interesting at this point - we haven't quite got a handle on the internal processes involved there (especially for modes 0-2), and the current plan is to use a model that's a reasonable approximation and tune it by ear.

As you noted, mt32emu-qt is our current focus, although we haven't forgotten about some outstanding bugs in the emulator.

Note that development might slow down for the next couple of weeks, but this is due to holidays/day jobs, not a lack of enthusiasm 😀

I have spent some time now checking several hours of MT-32 music, often preparing to post a bug report, only then to find that the error is either with the games' MIDI player itself or DosBox' emulation of it, and not MT32Emu. Brilliant!

I have since begun rerecording game soundtracks previously done using real LA units, using handy SMF2WAV for noiseless "recording". Most of the time however is spent recording each song twice because of insufficient partials, and extending the duration so that SMF2WAV will generate samples until the output has settled to zero.

Given that I'm unable to compile from sources myself at this time, may I request a version of SMF2WAV that:
1) has a command-line option for more than 32 partials (64 or adjustable)
2) has a command-line option for generating samples even after all tracks in the MIDI file have ended until the output has settled to zero.

Thank-you very much in advance.

Hi NewRisingSun, I'm glad to hear the latest Munt version is working out so well for you.

I'm a little confused regarding request (2) - mt32emu-smf2wav by default waits until the emulator output has settled to zero. Which version are you using?

A command-line argument for specifying the number of partials sounds reasonable, and we'll add that at some point.

You mentioned that you can't compile from source at the moment - which platform do you need it built for?

Hi, thank you for your reply.
I'm using mt32emu-smf2wav from here:
https://github.com/sergm/munt_devel/downloads

It displays "mt32emu-smf2wav 0.1.1". I need a Win32 console application, similar to the one at the above address.

I haven't been able to get this version to generate samples until the output has finished sounding. I have attached an example MIDI file where the reverb tail is cut off.

Don't bite my head off, but:

Was the Colonel Bequest thunder bug above fixed?

Hi, ALL!

Serious Callers Only wrote:

Don't bite my head off, but:

Was the Colonel Bequest thunder bug above fixed?

Sadly, no 🙁
We need to do some analysis to find out the exact problem, and KG probably had no time to work out the topic.
But we didn't forget anything, don't worry!

Hi serge & KingGuppy - any progress in the past month? How does the qt integration go? And the die scans?
I hate to be nag, but I care deeply about this project, and I couldn't help myself 😀

Hi OmerMor,

Sergey had a holiday and I had some distractions, but we're getting back on track (coincidentally, we just exchanged some emails about this a few minutes ago).

I've been holding things up a bit wrt. mt32emu-qt - I need to flesh out some architectural stuff. On the positive side, we're now talking to a Mac guy - Stino - who I hope will be helping us with OS X support.

Regarding die scans, someone else has mentioned that they may be able to get them done. But the situation remains the same: We're still hopeful, but we're not delaying anything while we wait for them.

Thanks for the update KG. Keep doing your superb work.