NewRisingSun wrote: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.

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.

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).

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.

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.

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

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.

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.

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.

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?).

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

You do not have the required permissions to view the files attached to this post.