Munt Reloaded - Development

[sergm]

If I disable libmt32emu_SHARED and libmt32emu_C_INTERFACE in CMake, compilation of DOSBox fails with "Incompatible setting MT32EMU_API_TYPE=3".

Right, libmt32emu_C_INTERFACE must be enabled as this is now required by the patch. This

Code: Select all

#define MT32EMU_API_TYPE 0

is certainly not right. MT32Emu::Service is only defined with the other API types.

OK, I managed to build a static library using MSYS2/MINGW64-i686.

Not sure, are you linking the library with DOSBox compiled using another compiler? If so, I think it's always safer to link dynamically.

[sergm]

I seemingly found an easier way to compile all with MinGW. There is a set of compiler options defined in CMakeLists.txt:

Code: Select all

if(CMAKE_COMPILER_IS_GNUCXX OR CMAKE_CXX_COMPILER MATCHES "(^|/)clang\\+\\+$")
  add_definitions(-Wall -Wextra -Wnon-virtual-dtor -Wshadow -Wold-style-cast -ansi -pedantic)
endif()

Stripping out "-ansi" will allow the currently broken MinGW to compile the library successfully.

[sergm]

Here is more evidence of remaining problems with the v1.07 MT-32 ROM using smf2wav x64 from MUNT v2.1.0. The archive contains an initialization sysex and a MIDI file from "The Colonel's Bequest".

Here is how it sounds with CM-32L ROMs (correct). And here is how it sounds with MT-32 v1.07 ROMs. Note the strange low-frequency drone which is not supposed to be there. I don't know whether it's a reverb problem or something pecular to that swamp sound effect timbre.

If I got it right, this is kinda supposed. That static high-pitched noise in background is not how old MT-32 should sound. Well, fairly saying, munt doesn't sound exactly how a real MT-32, though. Anyway, see if this post is related.

[NewRisingSun]

I suppose we are talking about the SwmpBackgr instrument. MUNT with CM-32L ROMs indeed emulates the new-type MT-32 faithfully, but when using the MT-32 ROMs, MUNT's output does not match any real module.

Here is a recording of the same song that I have just made from a real v1.07-ROM-bearing MT-32 unit. The high-pitched noise is indeed absent. But rather than reproducing the euphonic distortion of the actual module, MUNT with v1.07 MT-32 ROMs produces a low-pitched drone. (And yes, I have tried the integer renderer as well.) Maybe this aspect can be addressed in a future version.

And good thing I have not updated MingW yet. I'm planning on switching to MingW-w64, but am postponing it because I cannot be bothered to rebuild all libraries again, and risking trouble when recompiling DOSBox.

[sergm]

I really really really hope to get the old MT-32 quirks emulated properly soon. This is a shame that MT-32 emulator does not emulate these...

[NewRisingSun]

I have got a whole set of .SYX/.MID archives with descriptions that exhibit MT-32-specific differences, that I can upload if that is of any help to you.

[Yesterplay80]

Stripping out "-ansi" will allow the currently broken MinGW to compile the library successfully.

Thank you very much, this worked perfectly and I was able to compile DOSBox with MT32EMU 2.1.0 succesfully in MinGW! That's great because SDL_sound seems to have problems when compiled with MinGW64.

[sergm]

NewRisingSun

Oh, that sounds like being definitely helpful!

[NewRisingSun]

The first archive demonstrates games that are sometimes mentioned as sounding different between MT and CM, but which MUNT (as far as I can hear) emulates correctly when using v1.07 ROMs.

The second archive demonstrates games that MUNT does not seem to emulate correctly even with v1.07 ROMs. They consist of three groups:
1. Wrong pitch: Kick drum in Police Quest II (very audible), Flute-like bird sound in King's Quest 5 (only audible when in direct comparison), scratching sound in The Colonel's Bequest's 2.MID too low pitched.
2. Wrong envelope: Instruments decay too quickly: Guitar in Dune 2 (extremely audible) and Willy Beamish (still audible), "Taiko Cym" in Strike Commander (audible when you know what you're looking for)
3. Other: SpaceAlvin hardly audible in Space Quest 1; Swamp sound effect in The Colonel's Bequest is more of a rumble in 10/13.MID.

[sergm]

Thanks a lot! I'll investigate these three issues.

BTW, is there anything known about bugs of e.g. ROM v1.04 which were fixed in v1.07? Are you aware of any of those being abused in some games?

[NewRisingSun]

Here is the changelog from the MT-32 Service Notes, Second Edition.

Code: Select all

CHANGE INFORMATION (変更情報)

EFF. SN 823200   ROM Program Revision
  IC27 ROM A
  IC26 ROM B   Ver. 1.04 to Ver. 1.05
 
Change the taper of VOLUME control by changing the programs in the ROMs. Result: Smoother volume change in response to VOLUME setting change.

製番823200以降　ROMバージョンアップ　◯Ver. 1.04→Ver. 1.05
マスターボリウムによる音量変化を聴感上自然なものとする。
--
EFF. SN 836200   ROM Program Revision
  IC27 ROM A
  IC26 ROM B   Ver. 1.05 to Ver. 1.06
 
To reset Bender Control change in rhythm section when All Parameter Reset (MIDI) is received or Active Sensing is not recognized.
To not change displays even Display Change exclusive MIDI message is recognized unless the current mode is Master Volume input made (e.g. Power-up default).

製番836200以降　ROMバージョンアップ　◯Ver. 1.05→Ver. 1.06
MIDI機能
オールパラメータリセットまたはアクティブセンスが切れた時リズムパートのコントロールチェンジをリセットするように。
表示変更のエクスクルーシブメッセージを受取ってもマスターボリウム入力モードでない限り表示を変えない。
--
EFF. SN 838700   ROM Program Revision
  IC27 ROM A
  IC26 ROM B   Ver. 1.06 to Ver. 1.07

For stable program operation.
If the program won't start after replacing SRAM IC29 or 31, use ROMs of Ver. 1.07.

製番838700以降　ROMバージョンアップ　◯Ver. 1.06→Ver. 1.07
プログラム安定化のためSRAM IC29 またはIC31交換後にプログラムがスタートしなくなった時は、Ver. 1.07のものと交換して下さい。
--

I have included the Japanese descriptions, as their Google Translations are more intelligible than Roland's own English.

I don't think that any of these changes can be used or abused by games. The VOLUME-related change appears to refer to the volume knob, not the MIDI volume controller 7 or the main volume system exclusive message.

[sergm]

I don't think that any of these changes can be used or abused by games.

Yeah, especially that change from v1.06
Anyway, thank you for the useful info.

[HunterZ]

I may have already asked this, but can someone write an idiot's guide to getting Munt (including the Qt GUI app) to build on Windows?

I was thinking of trying to write something that replicates the MT-32 LCD on my Logitech keyboard's LCD, but I couldn't get a combination of MSYS2, CMake, and QT Creator that would actually build Munt for me.

Edit: Eclipse also works for an IDE, but I figured Qt Creator might be easier due to the Qt dependency.

[sergm]

Sorry, HunterZ, but I feel too biased to write an idiot's guide Anyway, I'm glad to help otherwise.

First of all, I'd recommend using the whole Qt toolset. It seems nicely bundled comparing to customizing that stuff manually. So, I'd just get Qt from here. This way you get both QtCreator and MinGW 5.3 toolchain that is known to work just fine with munt. The standard installation of Qt should also be perfectly detected by CMake automatically, and the QtCreator should have the toolchain automatically configured upon first launch. So, I hope no special steps are required, except setting

Code: Select all

CMAKE_BUILD_TYPE:STRING=Debug

to be able to do debugging and

Code: Select all

CMAKE_BUILD_TYPE:STRING=Release

for release builds. If you don't want mt32emu_smf2wav and like to avoid bothering with GLib, you may also disable munt_WITH_MT32EMU_SMF2WAV option.

[HunterZ]

Thanks!

Actually, your suggested approach was what I tried first, but GLib is what killed me. It's also what continues to kill me, as MSYS2 CMake is able to find glib-2.0 via your package finder module, but something ends up building bad paths to it.

I guess I'll try putting MSYS2 aside again and following your instructions to skip mt32emu_smf2wav (which I indeed to not need).

Update: Got mt32emu + mt32emu_qt building in qtcreator! Now I have to figure out how to link in the Logitech .lib library; looks like this may require having qtcreator build via the Microsoft toolchain (ugh).

Update 2: Got it building & running with the MS toolchain via qtcreator, including linking the Logitech .lib. Now to start hacking on mt32emu_qt.

[HunterZ]

Update 3: Got it working! Unfortunately I've got to go to bed, but I'll try to post some Youtube videos tomorrow evening. I want to capture (1) the Munt Qt GUI and the Logitech LCD emulator running side-by-side, and (2) the physical G15 v2 keyboard LCD display in action.

Right now it basically just replicates the physical MT-32 LCD + LED. It would be cool to have additional screens to provide the other emulator status from the Qt GUI, with cycling via the keyboard's LCD buttons, but I'm happy to get this far.

P.S. The Logitech LCD API is pretty dumb. It's all globally-scoped free-standing functions. You basically get a 160x43 pixel "background" layer that is sent as a byte-per-pixel (yes, byte, despite being a monochromatic LCD) array of unsigned 8-bit chars, and a "foreground" layer comprised of 4 lines of proportional font text. The background and text layers are independent, such that you have to actually set a text row to an empty string to prevent it from covering up the background, even when you are updating the background. You have to call an update function to commit changes to the physical display, which I guess is nice because it allows you to basically double buffer the output. The only real issue I ran into with all of this is that Munt's LCD and LED widgets update independently, but on the Logitech LCD they share an output buffer (unless I want to make the LED text-based, which I might try).

I'm also not sure how to package the damn thing, since I had to build it with the MSVC toolchain in Qt Creator. There end up being a ton of DLL dependencies, both Microsoft and Qt. I'll try to figure something out if people are interested in playing with it; otherwise I'll probably just put the source on a Munt fork. I did make sure to add this stuff into CMake as an optional feature+dependency.

[Dominus]

Cool!

[HunterZ]

Here are a couple of videos:
Side-by-side of mt32emu-qt GUI and Logitech LCD simulator: https://youtu.be/Rb38ZCy6MRc
Cell phone video recording of real Logitech LCD: https://youtu.be/ExRFasoLT7o

I'll get the source and a binary release out tomorrow. Took a long time to figure out what Qt DLLs I needed to include to get everything working right. Munt normally solves this by linking them all in statically, but apparently this is not an option when building with the MSVC toolchain (which I have to use in order to be able to link the Logitech LCD lib) because CMake insists on dynamically linking system libs The good news is I have fairly high confidence it will run for other people (well, except for Windows XP people), since I did all my recording on a separate machine than I built on.

[HunterZ]

Logitech LCD prototype source is up on a fork here: https://github.com/HunterZ/munt/commit/ ... fd4e3bbe66

Do whatever you want with it.

Pre-built binary release is here: https://github.com/HunterZ/munt/release ... gitech-1.0

I should probably try switching back to MinGW now that I've found some potential options for converting the logitech .lib to .a format. I still don't understand why I couldn't get Qt Creator + CMake to link it with the 32-bit MinGW toolchain, as this is supposedly supported by MinGW (maybe CMake or Qt Creator are the problem?).

[Falcosoft]

Hi,
I would like someone to confirm whether this is a bug or an MT-32 feature (not known by me) that Munt emulates properly:
When a program change event happens Munt resets the Pitch Bend Sensitivity RPN (0, 0) to MT-32 default 12. It seems counter-intuitive for me and GM devices definitely do not do this.
I have made a test file :

Mt32_test.zip

The midi file only does the following:
1. Sents a Reset message.
2. Plays a note and changes the pitch (because of reset it uses MT-32 default Pitch Bend Sensitivity 12)
3. Changes Pitch Bend Sensitivity to GM default 2.
4. Plays another note and changes the pitch (so it uses GM default Pitch Bend Sensitivity 2)
5. Changes Program 0 to 1.
4. Plays another note and changes the pitch. I think it should use Pitch Bend Sensitivity 2 but instead it uses the default 12.

MT32_test.jpg

Thanks