Can anyone think of a way to do automated testing?

Yes, we've had plans for this for some time. The closest we have right now is tools to:

- generate thousands of combinations of timbre parameters, MIDI notes, velocity, etc.
- send the MIDI to the real CM-32 and capture the digital output
- send the same MIDI commands to Munt and record its output (using mt32emu-smf2wav)
- give statistics on the accuracy of each combination and help track down any problem areas

Our future plans include recording the values poked to I/O registers by the MCU on the real device (via the real thing or CPU emulation) and comparing it to Munt's equivalent.

These tests are complicated by the fact that we're not quite bit-perfect yet (though getting very close in many respects). Also, due to the asynchronous interactions of MIDI input, timers, communication between the CPU and LA-32 and so on, the sounds are generated somewhat nondeterministically (they can differ on each run).

sergem: I see that you're busy adding LCD support to the emulator which is great. I hope we'll have a chance to play with it soon 😀 Thanks!

yep, coming soon: mt32emu-qt Xmas edition 😀

Current build of Qt-based GUI-enabled mt32emu for Win32.
https://github.com/downloads/sergm/munt_devel … _2011-12-10.zip

It needs installed and working mt32emu MIDI driver, though it's included and accompanied with trivial drvsetup.

For linux you'll need to type at least:
cmake .
make
sudo make install

to build from sources.

For porting to Mac OS X we strongly need CoreMidi / CoreAudio module, so any help is appreciated.

The installer does not like Win7.

And who likes? 😀

sergm wrote:

And who likes? 😀

Steve Ballmer:
http://www.youtube.com/watch?v=wvsboPUjrGc

Shouldn't coremidi module be straightforward when you look at how dosbox, scummvm, exult implement it?

Personally I'm passing on qt stuff, too many dependencies that screw things up (I'm biased, had to do something with it once, two years ago and that didn't work out)

@Leolo:
sort of 😀 Just going crazy...

@Dominus:
Currently, we've difficulties with both coding and testing on Mac OS X. Thus, we need (your) help. Although, finding working GPLed RTP-MIDI capable class should solve the problem eventually.

I can try stuff out but can't code. Especially when I promised Collector some stuff a year ago... 😀

Oh! Sounds like worth a try 😀 Anyway, Mac OS X support is the next milestone for me 😀

sergm wrote:

And who likes? 😀

Many do, but that still does not address the problem of the installer.

sergem: I have a working munt driver installed on my win7 machine.
When I run mt32emu-qt.exe and select Tools-->Test MIDI Driver I get the following error message:
---------------------------
Cannot open Synth
---------------------------
Control ROM file cannot be opened.
---------------------------
OK
---------------------------

And this is what gets written to the console before the process crash:
Init Error - Missing or invalid Control ROM image
Failed to open qSynth

Any help would be appreciated.

The only legal way to get the mt-32 ROMs is to rip them from a real device.

I have both a real device, and the roms.
however - I managed to get this thing working. Apparently - the emulator does not like my mt32 control rom, but it does accept my cm32 roms so everything works now. I had to use the qt app to set the roms (and then found out were they are in the registry so I could confirm this was the case).

Can you tell me why my mt32 control rom is not accepted (not shown in the rom selection dialog)?
It has the following SHA1 hash: 7B8C2A5D-DB42FD07-32E2F22B-3340DCF5-360EDF92

I just saw in the source that it expects an MT32 control rom with SHA1 hash of B083518F-FFB7F66B-03C23B7E-B4F868E6-2DC5A987.
Does that mean that my ROM is corrupt, or that there was more than one version of it?

OK - I managed to find the mt32 control rom that match your sha1 hash.
From the rom file I can see it is ver1.07 from 10 Oct, 1987.
My control rom states is is verX.XX from 30 Sep, 1988.

It doesn't accept my MT32_CONTROL.ROM, either.

As you can see from sources, only ROMs with known (hardcoded) size / sha1 digest are supported, and currently there're only 2 sets of ROMs available. The plan is to add many more ROM infos and to make emulation distinctive depending on each ROM set.