MT-32 Support causes game instability in Might And Magic: World of Xeen

[romatthe]

This concerns an apparent compatibility issue with Might And Magic: World Of Xeen (MM4/5) and the Boxer Roland MT-32 support. I believe this issue was reported earlier in #32, but the actual issue itself contains very little info on what does or does not work, and what workarounds were used.

In short, running the game with Roland MT-32 support seems to make it very unstable. The game crashes primarily when voice clips are being loaded (when entering dungeons, going by the shops, etc.), but also on totally random intervals (these are less frequent and consistent than the voice clip crashes).

When I set everything to use Sound Blaster Pro, I experience none of the crashes, but obviously I also don't get any MT-32 support, which is actually really nice in the Xeen games.

One thing that I find extra curious that I recently finished the the prequel of the Xeen games, Might and Magic III: Isles of Terra, with full MT-32 support turned on. The game didn't crash a single time and there were zero instabilities. I played this with the exact same version of Boxer as I'm playing World of Xeen now. Considering that Xeen's engine is very similar to that of Terra, it seems strange that they behave so differently.

On top of that, it also seems strange that many crashes occur when trying to play voice clips, as its obviously not the MT-32 that provides the speech playback.

Are there any known workarounds aside from disabling MT-32 support?

Info: World of Xeen version: As sold by GOG.Com Boxer Version: Version 1.4.0 | build 20160216-1.4.0 OS: OSX 10.12.1 Sierra

Unstable:

Stable:

[kode54]

This topic won't answer your question, but may point you in a different direction. Namely, it may be better to use this particular game with its SC-55 option, with the Roland Sound Canvas VA synthesizer. I kind of want to make it possible to use that from Boxer, and I think I raised a feature request somewhere.

The major prohibiting problem with SCVA is that it costs freaking $125, when they sell a 100% identical synthesizer in the form of an iOS app for $20. I guess they imagine people still using their synthesizer to author music for digital output using multi-track editors.

Just for reference, the Audio Unit implementing the Sound Canvas Core library has a component manufacturer of 0x726f6c44 ('rolD') and subtype of 0x53633535 ('Sc55').

[almeath]

On the subject of MT-32 support in Boxer, does anyone know if it is possible to get the latest version of MUNT working in Boxer 1.4 or 2.0?

I looked in the contents of 1.4 and I see there is a "MT32Emu" package in the frameworks folder. Can this framework be updated in isolation of the rest of the app, perhaps utilizing the "Boxer-MT32Emu" framework that Alun provides?

If Boxer will not be updated anymore it would be good to at least hack 1.4 or 2.0 to keep up with upgrades to MUNT, which incidentally might solve the above problem.

[JoshuaPettus]

Well alun does have a project to make a framework out of the mt32emu library. I use to update the xcode file with the latest code , build it and plop it into the boxer app. Many times I didn't need to recompile. But I think the changed up the api in 2.0.

I think it is easier to build the munt qt app. Then point boxer with the dosbox settings before launching your game: mididevice=coremidi and midiconfig=# (usually 1 or 2)

[almeath]

The munt qt app is available pre-built via SourceForge: https://sourceforge.net/projects/munt/

The app seems to set the port name to "Mt32EmuPort1" by default. So, the settings I used in the Boxer 'DOSBox Preferences.conf' file were:

[midi] mididevice=coremidi midiconfig=Mt32EmuPort1

And that worked like a charm. Definitely easier than trying to compile a custom framework to drop into Boxer, as I ran into all sorts of trouble trying to build that in Xcode 9.2. I do not think that approach will be viable unless Alun starts updating the Boxer-MT32Emu fork, and as you mentioned above it will be useless for Boxer 2.0 alpha due to more fundamental changes in the app.

The only downside to this approach is that munt needs to be launched separately before starting Boxer, but I edited the info.plist in munt so that it at least does not show up in the Dock and can then be set as a login item and always run in the background. Munt seems very easy going on system resources.

[vcalic]

You cannot just replace MT32Emu.framework with new one in existing Boxer binary bundle, but it seems to be possible to recompile Boxer-MT32Emu with latest Munt source, and then use that one to compile 2.0.0-alpha.

Here's what seems to work with Xcode 9.2:

• take the latest Munt source, got into mt32emu, ran cmake .
• added files from src folder to munt folder inside Boxer-MT32Emu project.
• inside Boxer-MT32Emu switch target to Framework and build 32-bit version.
• take the compiled framework and replace existing one in Boxer source
• Rebuild Boxer

Compiled binary is not without problems (well, it is alpha, so I guess we cannot complain) but MT32 emulation seems to work.