munt / munt

A multi-platform software synthesiser emulating pre-GM MIDI devices such as the Roland MT-32, CM-32L, CM-64 and LAPC-I. In no way endorsed by or affiliated with Roland Corp.

This repository consists of several related subprojects collected in one place for convenience.

mt32emu

mt32emu is a C/C++ library which allows to emulate (approximately) the Roland MT-32, CM-32L and LAPC-I synthesiser modules.

mt32emu_alsadrv

Comprises of a GUI and a console applications that make use of mt32emu library to provide emulation services via ALSA MIDI sequencer interface for Linux applications. Applications that rely on raw ALSA MIDI ports may connect via virtual raw MIDI ports, e.g. created with help of snd_virmidi kernel module. The GUI application is mostly obsolete and can be replaced with mt32emu_qt. Still, mt32emu_alsadrv may be preferred for systems with limited resources.

mt32emu_smf2wav

A console application intended to facilitate conversion a pre-recorded Standard MIDI file (SMF) to a WAVE file using the mt32emu library for audio rendering. The output file is equivalent to a direct recording from a Roland MT-32, CM-32L or LAPC-I synthesiser module.

mt32emu_win32drv

Windows MME driver that provides for creating a MIDI output port and transferring MIDI messages received from an external MIDI program to mt32emu_qt, the main synthesiser application. It also includes the mt32emu engine built-in and is able to operate in stand-alone mode if the main application mt32emu_qt is unavailable.

mt32emu_win32drv_setup

Helper tools intended to simplify installation / upgrade of the Windows MME driver mt32emu_win32drv.

mt32emu_qt

The main synthesiser application. It facilitates both realtime synthesis and conversion of pre-recorded SMF files to WAVE making use of the mt32emu library and the Qt framework. Key features:

1. Support for multiple simultaneous synths with separate state & configuration.
2. GUI to configure synths, manage ROMs, connections to external MIDI ports and MIDI programs and interfaces to the host audio systems.
3. Emulates the funny MT-32 LCD. Also displays the internal synth state in realtime.
4. Being a cross-platform application, provides support for different operating systems and multimedia systems such as Windows multimedia, PulseAudio, JACK Audio Connection Kit, ALSA, OSS and CoreMIDI.
5. Contains built-in MIDI player of Standard MIDI files optimised for mt32emu.
6. Makes it easy to record either the MIDI input or the produced audio output.
7. Simplifies batch conversion of collections of SMF files to .wav / .raw audio files.

DOSBox-mt32-patch

Patch for the official DOSBox release v.0.74 to demonstrate a possibility to add mt32 MIDI device. Intended for developers and maintainers of customised DOSBox builds.

FreeBSD

Files related to the port of munt components for the FreeBSD system.

munt's Issues

Possible access to uninitialised memory of rhythm timbres

When using an image of any version of MT-32 control ROM, the internal data structure that holds predefined stock rhythm timbres is not utilised in full. We allocate memory for that structure so that all 64 timbres defined in CM-32L / LAPC-I can fit, but MT-32 only uses 30 of them. During initialisation with a MT-32 control ROM, only 30 stock timbres are placed in the memory in fact, the rest remains uninitialised. This should be OK as the code performs a corresponding check when starting to play a note on the rhythm part.

However, some games practice programming patches with the standard rhythm timbres to be played on the melodic parts instead. The code that performs range checks during defining such patches cannot interfere, because the rhythm timbres which are only defined in CM-32 are still within the valid range 0..63 (that is applied to every timbre bank equally). The code that actually configures a new note to be played also does not contain any validity checks to prevent playing non-existent rhythm timbres on a melodic part. As a result, the behaviour is undefined in case a CM-32L / LAPC-I game attempts to play such an instrument (can vary from being silent to producing unpleasant squeaks).

Interestingly, the new-gen MT-32 devices seemingly contain a fix for this issue, as the table that defines the standard rhythm timbres contains 64 entries, with timbres 30..63 being mapped to OFF. Evidently, the emulation should initialise this part of memory as appropriate to fairly emulate the new-gen units and to avoid undefined behaviour when emulating the old-gen units (even if the latter really do exhibit it).

Update: in case of old-gen devices, the rhythm timbre played seems to be picked from the standard ones modulo 30. But this is not consistent. For example SysEx F0 41 10 16 12 05 00 00 03 3C 3C F7 sets patch 0 so that playing a note on an old-gen unit (with control ROM 1.07) makes it hang. That is, rhythm timbres 0..59 are only "valid" for the old-gen units, because they display more-or-less sane behaviour.

Implement support for bitwise ROM dumps

Currently, the library is only capable of loading post-processed ROM images that resulted from interleaving the original files with ROM IC dumps each of which contain bytes written to either even or odd addresses. This implies that the user has not to merely dump the contents of the ICs but also merge the corresponding "halves" into one complete file.

OTOH, when the ROMInfo class was first introduced, it was already foreseen to register those "raw" files with bitwise ROM dumps with the intention to create a complete ROM image automatically from several files, provided they are identified.

Task: Add support for handling multi-file ROM images as appropriate and add the metadata for known bitwise dumps of ROM ICs.

OSX binary

Can I request binary compiled for or compatible with OS X El Capitan 10.11.6?

Function mt32emu_configure_midi_event_queue_sysex_storage inaccessible in shared library builds

Despite being defined in the public include file c_interface.h, function mt32emu_configure_midi_event_queue_sysex_storage does not declare the exported symbol in the resulting shared library which makes it inaccessible for users of shared library builds.

Errors in mt32emu 2.5.0

I apologize in advance if my style of presentation seems rude and tactless. I have a poor grasp of spoken English and express myself in the language of technical documentation.

0 Project self-identification. munt or mt32emu?
You originally named the project munt, but the library and executable are called libmt32emu and mt32emu-qt respectively.
I thought you called the project munt before, then changed your mind and wanted to call it mt32emu. The decision is very correct in my opinion.
But you release both munt 2.4.0 and mt32emu 2.5.0 simultaneously with almost the same content.
What is this and how do I understand it?

1 ChangeLog mt32emu-qt

HEAD:
* Fixed the ROM scanner function that didn't filter out partial ROMs which aren't yet supported. Related to (#44).

Is this fixed in mt32emu 2.5.0 or not?

2 You added the pakageconfig file which is great, but you missed at least 2 gross errors.
2.1 The resulting mt32emu.pc file when built in openSUSE Tumbleweed x86_64 is

prefix=/usr
exec_prefix=${prefix}
libdir=${exec_prefix}//usr/lib64
includedir=${prefix}/include

Name: libmt32emu
Description: C/C++ library to emulate (approximately) the Roland MT-32, CM-32L and LAPC-I synthesiser modules
URL: http://munt.sourceforge.net/
Version: 2.5.0
Requires.private: 
Libs: -L${libdir} -lmt32emu
Cflags: -I${includedir}

2.1.1 Obviously, the 3rd line should be.
libdir=/usr/lib64
But something, most likely in the sed script, went wrong.
2.1.2 The URL is not needed in this file at all. I haven't seen other open source projects post URLs here.
But if you think that it is still needed, then let it link not to http riderect 80, but to the https address of the project on github.
2.2 After the %cmake_install macro, the mt32emu.pc file is installed in %{_prefix}/lib/pkgconfig/%{name}.pc (/usr/lib/pkgconfig/mt32emu.pc) instead of %{_libdir}/pkgconfig (/usr/lib64/pkgconfig/mt32emu.pc).
There must be an error in the installation script.

3 You added a desktop-file for mt32emu-qt which is great, but at least the category is wrong.
https://build.opensuse.org/package/view_file/multimedia:libs/mt32emu/mt32emu.desktop?expand=1
It should be Categories=Qt;AudioVideo;Midi;
It's also not clear why they even mention munt if it's mt32emu... but that comes from point 0.

4 You added an icon for the desktop-file that's great too, but there's nothing wrong with it either.
4.1 This is a primitive 256x256 png icon.
Why do you need such a big size, and it's the only size you need, for such a primitive monochrome icon?
Linux does this in 2 ways.

• It is broken into smaller ones in /usr/share/icons/hicolor/NxN/apps/mt32emu.png, where N necessarily contains 16, 32, 64, and optionally 128 and 256.
  But in this case, I don't understand what the dimensions of 128 and 256 are for such a primitive monochrome icon?
• If you're too lazy to break into multiple files, create a vector svg or svgz icon and put it here /usr/share/icons/hicolor/scalable/apps/mt32emu-qt.svgz Then the icon in the maximum possible quality and it does not need to break into smaller.

In general you need to do something from this, if you choose the 1st option, I recommend to limit the size 64. Well, a maximum of 128, I do not even know why.

Introduce support for symbol versioning

As of libmt32emu version 2.4.x, we're already tracking versioning of each public symbol of the C interfaces. This enables easy runtime compatibility checks when loading a shared library into a client application yet this is a cross-platform solution.

However, in some cases it is advantageous to bind each public C and C++ symbol with the library version when it was introduced as well. It'll enable an application developer to quickly determine the version requirements when necessary. This is particularly important when packaging the library on Linux systems, because advanced packaging systems provide a way to derive dependency requirement automatically based on the ELF symbol versioning, which simplifies the maintenance effort yet ensures reliable packaging.

Due to the above, each exported library symbol should have an additional version tag to clearly document its version of origin, thus providing a way of automatic generation of platform-specific version map files (or attributes) as suitable.

[Feature] Integrate a patch editor into the Qt GUI

The pitch
I've been bashing my head against the wall for months now trying to make MT-32 patches by routing the handful of patch editors that support the MT-32 into MUNT (both the Qt Standalone or Falcosoft's VSTi), and all I've gotten from it was lost hours and clumps of hair.

Figuring out how to send SYSEX commands... How to formulate a MT-32 SYSEX command... Trying to send anything from the editor to the software usually to no avail... And that's when it hit me.

The execution
If MUNT is emulating the MT-32, wouldn't it be trivial to directly modify the registers without jumping through any hoops at all? I can imagine a GUI function of double clicking a channel, seeing a nice and fancy editing screen, and editing the memory itself all in real time. No fuss, no muss, no MIDI commands at all.

In fact, I could also see a part of that GUI neatly providing a means of exporting well... anything as a SYSEX MIDI/.syx file.
It would read the state of the timbre/patch/bank in the editor, but not in the MT-32's memory itself (unless you want to take such an approach), and provide a choice of exporting the parameters in a singular SYSEX by itself or as a string of SYSEX commands for initializing and writing multiple timbres into the MT-32's memory for a whole song, everything all ready to go and waiting to be sequenced.

The summary
However you slice it, making patches for the MT-32 these days, especially internally in software using MUNT, is an exercise in convolutedness and futility. There's already a perfectly good Qt GUI interfacing MUNT as a whole, and an earlier suggestion of using the Qt GUI to select the preset timbres was received well. Why not go whole hog?

Right-shifting by 32 is too far for 32-bit int type (undefined behavior)

Flagged by gcc version 10.2.0 (Ubuntu 10.2.0-13ubuntu1) when libmt32emu is instrumented with Undefined Behavior Sanitizer detection:

MT32: LCD-Message: INSERT BUCKAZOID
MT32: LCD-Message: * SPACE QUEST III *
munt-libmt32emu_2_4_2/mt32emu/src/TVP.cpp:343:57: runtime error: shift exponent 32 is too large for 32-bit type 'int'

Compile error when using MT32EMU_RUNTIME_VERSION_CHECK 2 from a C program

Apparently, the header file VersionTagging.h is missing support for C language and requires C++ language features currently. By design, it was intended to work when the main header mt32emu.h is included from either a C or a C++ translation unit (having defined MT32EMU_RUNTIME_VERSION_CHECK 2). This should be fixed.

C interfaces missing explicit calling convention decorations

When building for x86, there are several calling conventions (__cdecl, __stdcall, __fastcall). The options passed to the compiler when creating the mt32emu DLL appear to default to using the __cdecl convention. This is fine for building the DLL.

However, consumers of the DLL might be compiled with different calling conventions, and so it would be better if all the functions in c_interface.h and all the function pointers in c_types.h were explicitly decorated with __cdecl.

For example, I am working on a project that uses __fastcall by default. In order to properly load and call into the DLL, I had to modify c_types.h to explicitly add __cdecl to all the function pointers defined in the interfaces.

(This is for MSVC specifically, but in general on x86 it is best for DLLs to be explicit about the calling convention.)

[Enhancement] Dark theme

The floating LCD would look even better if its window border were removed and the background of the MIDI MESSAGE indicator matched the black case of the MT-32.

A bonus would be if mt32emu_qt had a dark theme option.

mt32emu_qt 2.7 AppImage | Cinnamon 5.2.7 | Linux Mint 20.3

Guides or information on dumping MT-32 ROM?

Are there any guides or information on dumping the MT-32 ROM from a real hardware unit?

I know there are illegal ways to obtain these ROMs but I have a real MT-32 that I'd like to desolder/dump the ROM myself if possible.

[Feature] Play the demo

I'm not sure if it's currently enabled or not (searching for "demo" doesn't return anything), but it would be nice to be able to trigger the demo mode and play the demo songs that are stored in the rom. Is this possible?

Convenient functions to simplify selection of ROM files in applications

At present, applications are left alone with configuration of files containing ROM dumps to use in the emulation engine; the latter merely expects a client application to provide ROM images to use as necessary. There are barely any means available to facilitate e.g. scanning a directory to find files that contain dumps of all known ROMs, or ROMs of particular type that may be configured in the application settings rather than specifying exact names of files.

Also, a C++ application that relies on using low-level classes ROMInfo and ROMImage (that is, uses MT32EMU_API_TYPE 0) can easily identify a ROM file by calling method ROMInfo::getROMInfo, whereas such function is still unavailable for C applications.

Task: Provide new public C functions for:

1. retrieving the id and the description of a ROM image contained in a file or a data array;
2. identifying filenames of ROM images of particular types in a specific directory, so that they comprise a complete set of compatible ROMs that can be further supplied to the emulation engine.

SC-55 emulation

MUNT is a very accurate emulator as far as the Roland MT-32 is concerned, unfortunately the Roland SC-55 currently doesn't have an emulator. There are many soundfonts that try to imitate it but fail in many ways.
Almost a year ago progress was made for decoding ROMs in this forum: https://www.vogons.org/viewtopic.php?f=62&t=76613&start=320, a tool was created to convert ROMs to soundfont .sf2 (https://github.com/Kitrinx/SC55_Soundfont) but since then everything has stood still, and in any case the developer himself has admitted that the .sf2 format is unable to accurately express the SC-55.

Provide API for retrieving sound group configuration

This is a useful feature for implementing #70 so that the UI may always display the actual list of sound groups and their content when the user is choosing a new instrument for a part.

mt32emu-qt: add command to CLI for opening one or more MIDI port(s) at startup

Since the GUI application does not foresee storing the layout of opened synths and MIDI sessions in settings, we always have to start fresh on startup or after a restart. However, it'd be nice to have an opportunity to create a predefined set of MIDI ports (which are reflected in creation of the respective system MIDI endpoints, opening system MIDI input devices, etc.) automatically for some use cases.

This is especially relevant for the JACK MIDI because the application currently requires GUI interaction to create any JACK MIDI endpoint. Instead, the CLI should offer a dedicated command to create a number of JACK MIDI ports, including those working in the exclusive (fully synchronous) mode.

Improve CMake build scripts

CMake build system should try its best at facilitating the search for the applicable dependencies. Notably, that includes checks for required version of components to ensure API compatibility.

Additionally, libmt32emu should make adding it to consumer applications easier in case they are also rely on the CMake build system. Providing a FindPackage module FindMT32EMU.cmake is discouraged, so that shall be replaced with a proper CMake configuration file, which also makes it easy to retrieve transitive dependencies (when applicable) and correct version information.

Suggestion: Allow changing instruments (program changes) from the QT GUI

Hi.

I don't have a problem with the way Munt currently handles things, since I'm well versed in MIDI by this point, am able to roll my own tools, and use ALSA which gives a decent amount of flexibility and control, but I have a Windows-using friend who might benefit from this.

He makes music, and took interest in my (real) MT-32 when I showed it to him. He wants to use Munt to make some new music of his own. He has a MIDI controller keyboard, but it doesn't provide a button or means to do program changes on it, so his first question to me was "how do I change the instruments?"

So I had to do this nasty hack with VMPK (which only uses General Midi instrument names unless you edit config files) to get him a way to manipulate instruments on Windows, which he promptly forgot how to do.

So my suggestion is relatively straightforward. In that 'drop-down' area that contains the channel statuses and partial states, instead of simple labels naming the channels, maybe there could be QComboBoxes, each containing all of the preset instruments on each channel.

Perhaps stored instruments could be shown in the boxes as well - but I think just exposing the presets would be enough, since that's all that the LCD and controls on the front panel of an MT-32 can do. If a custom instrument is set, a new item with that instrument name could be added at the top or bottom of the combobox, which self-destructs (disappears) if another preset is selected.

In short, since the real MT-32 has functionality to (awkwardly) set instruments from the front panel, I think it'd be nice if Munt could do so as well in the GUI.

Guidance needed: Packaging for Fedora

Hello,

I am trying to package Munt for Fedora. The motivation for this is the mt32emu library, but I will also attempt to package the applications. I kindly ask for guidance on how to handle Munt's monorepo approach.

For background, Fedora uses rpm packaging system. Rpm supports building once and splitting the resulting artifacts into multiple "subpackages". Initially, this seemed like a good approach for packaging Munt, since there is a top-level build script that builds all the parts. However, this ran into the following problems:

1. It is unclear which release tarball should be chosen. We would like to have latest stable versions of everything. However, looking at the contents of releases, it looks like the named component (e.g. mt32emu for release mt32emu_2_5_1) is at specified version number, while others are Git snapshots. Is there a way to get a single release tarball that only contains release versions, not snapshots?
2. Using the latest release munt_2_5_0 and building both mt32emu and mt32emu-qt, shared library is not built, instead static linkage is used to embed it inside mt32emu-qt. This is not what is wanted, for Fedora the correct configuration would be to build the shared object anyway, and use that with mt32emu-qt and other dependees. Is there a way to achieve this?

Another method would be to package all components separately: Start from component's latest release and build only that component. That would solve the first problem. For the second one, mt32emu shared object would be built, and the only remaining problem would be how to build the other components against that instead of static linkage.

I also have a minor complaint regarding how top-level CMakeFiles.txt sets parameters CPACK_PACKAGE_DESCRIPTION_FILE and CPACK_RESOURCE_FILE_LICENSE: Values for these are fetched from subdirectories FreeBSD and mt32emu-qt, respectively. Thus, even if only mt32emu is built, the other subdirectories have to be extracted. Of course they are there and thus everything works, but this prevents using a technique sometimes used in Fedora packaging: Removing all unused release tarball directories before building, to make sure that they are not used. This is useful e.g. to ensure that no content with unexpected licenses end up the build result.

I am willing to submit any changes that may be needed as PRs once it is clear what is the best path forward.

Standard patch #120 Cymbal is emulated incorrectly with old-gen MT-32 control ROMs

NewRisingSun reports about incorrect emulation wrt. slower decay and rather abrupt termination when playing said patch. Apparently, this is easily reproducible by just a ProgramChange-NoteOn sequence sent after a reset, like this:

TIMESTAMP IN PORT STATUS DATA1 DATA2 CHAN NOTE EVENT
 00003697  MOX  2     C1    77    --    2  ---  PC: Cymbal    
 00004335  KEY  2     91    3C    64    2  C  4 Note On       

See VOGONS topic for more background.

Standard MIDI file player may fail to send all-sound-off when stopping playback

Apparently, the SMF player fails to flush the queued MIDI messages before sending the all-sound-off sequence when being stopped and the corresponding SynthRoute is not in the multi-session mode. This bug was introduced since mt32emu-qt 1.8.0.

Enable the built-in Qt support for high-dpi displays by default

To improve UI look on high-dpi displays, the Qt library provides a number of ways to enable the necessary scaling the application layouts and the raster graphics (since Qt version 5.4). There are several environment variables, e.g. QT_ENABLE_HIGHDPI_SCALING (since Qt 5.14) or QT_AUTO_SCREEN_SCALE_FACTOR (since Qt 5.6) that should be configured before launching the mt32emu-qt application on a high-dpi display. However, this may likely become an issue on Windows systems only, because display scaling is never a problem on macOS, yet many GNU/BSD systems per-configure these environment variables for the user.

Besides, the Qt library provides a way to enable the high-dpi display support programmatically, which is clearly a more reasonable default behaviour for mt32emu-qt application. Even if the high-dpi display support enabled programmatically by default, this leaves the user a possibility to disable it via the same environment variables, if desired.

(minor) ROMImage should be freed with `delete[]` to match its `new[]` allocation

The Address Sanitizer caught this:

In ROMInfo.cpp, romImage's memory is allocated on line 227 with new[]:

Bit8u *data = new Bit8u[2 * partSize];

But it's released with delete (instead of delete[]) on line 273:

delete romImage;

Shared libraries should use -fPIC

The shared libraries should use -fPIC flag. This helps security (by allowing address space layout randomization to be used with the libraries)m but it also helps when building libraries that link to libmt32emu.

This can be easily set on cmake by using the following:

set(CMAKE_POSITION_INDEPENDENT_CODE ON)

at the appropriate location on one of the CMakeLists.txt files.

[mt32emu] provide a CMake config to easily include it as a library in other CMake projects

Hi,

It looks like that there is no Cmake config to easily include mt32emu as a dependency like for e.g.:
find(libMT32emu CONFIG REQUIRED) and then be "ready to be used".

I have opened a similar issue in vcpkg that is providing libmt32emu, but it is not really convinient without a CMake config.
Here as a reference:
microsoft/vcpkg#22273

Would it be possible to include a CMake config to simplify the use and configuration of the library?
(thanks)

[Enhancement] LCD always-on-top

First, my compliments for the continual incredible work on this project.

• Add an option for a movable always-on-top LCD instead of LCD balloons. To the right of the LCD, closer than on the physical unit, add the MIDI MESSAGE indicator but not the text.

The LCD looks great, however:

• For added accuracy, place the LCD characters in the grid that's visible on the physical unit (a width of 1 px of the native resolution should suffice).

Using mt32emu_qt 1.8.0 from MT-32_Emulator-x86_64.AppImage (until perhaps I resolve issues cmake throws).

[Feature Request] Partial exhaustion indicator in UI

It would be nice to have some kind of indicator that notes are being dropped or not played due to partial exhaustion, especially because this is an emulator that can just have more partials, if the end-user knows it needs more. 😄

It looks like there's a bunch of free room in the 'Synth' box in the UI, though it might make more sense to put it somewhere in the 'Partial State' area - maybe next to the 'Partial State' text itself?

[FEATURE] Allow single audio channel isolation

Hey folks! This is a feature request (unless it exists, and I'm just missing it...).

I have the standalone Munt emulator, and see that it can differentiate between different audio channels based on the instrument that's playing / MIDI channel that's being triggered. Would it be possible to implement, say, a mute checkbox next to each channel so that one could record / export each channel individually by isolating each channel? This would be great for folks like myself who can then import those tracks into a DAW, and give them a more modern upscaled mix for lack of a better term. Original audio. Original arrangements. Just higher quality.

Anyhoo. Munt sounds fantastic. If this feature is possible to implement it would be absolutely perfect for what I'm looking for! Thanks!

Cannot download MT32Emu-qt-1.8.0.dmg from Munt sourceforge.net

I cannot download MT32Emu-qt-1.8.0.dmg from Munt sourceforge.net and got the following error:

The geometry of the floating LCD can become inaccessible

In Cinnamon on Linux with multiple displays and the floating LCD on a secondary display at a window position beyond the resolution of the primary display, deactivating or disconnecting the secondary display moves the LCD to the primary display as expected but at an inaccessible window position.

Reproduction:

1. In Cinnamon on Linux, connect a secondary display having a resolution higher than the primary display.
2. Move the floating LCD to the secondary display beyond the comparable range of the primary display (such as to the bottom right corner).
3. Disconnect the secondary display.

The floating LCD is not visible on the primary display.

To restore the visibility of and accessibility to the LCD, activate or connect the secondary display.

Moreover, placing the LCD over a panel prevents the LCD from responding to left and right clicks, thus from being moved.

To restore access to move the LCD, modify the geometry value in ~/.config/muntemu.org/'Munt mt32emu-qt.conf' to a value within the range of the display that is beyond visible panel areas.

mt32emu_qt 2.7 AppImage | Cinnamon 5.2.7 | Linux Mint 20.3

DOSBox Patch LCD messages to LCDProc

Hello.
It would be great if we can set LCDProc server IP address and port directly in the dosbox.conf in order to get munt emulated LCD messages sent to real LCD hardware, since LCDd support seems to be completed.(#64).
Maybe not the most usefull feature of the universe, but.... Nice!
Thank you. Bye

Improve ROM files loading algorithm in the SMF2WAV conversion command-line tool

Current behaviour

Currently, the tool is only capable of searching two sets of ROM files in a specified directory. These two sets have hard-coded names ["CM32L_CONTROL.ROM", "CM32L_PCM.ROM"] and ["MT32_CONTROL.ROM", "MT32_PCM.ROM"], yet the CM32L files take priority over the MT32 ones. There is no check implemented wrt. correspondence these filenames to the actual machine model. Also, the priorities are hard-coded, it is not possible to make the tool load the MT32 files in case the CM32L files are present in the same directory.

Desired behaviour

The tool should feature a ROM scanning function. It should be capable of searching in a specified directory and loading ROM files for a particular machine model regardless of filenames. A new command-line option (e.g. -i / --machine-id) should be introduced for specifying either the exact desired machine model or a pattern. The backend for this feature becomes available in libmt32emu with #47.

• When the exact machine model is specified, the corresponding ROM files of all known types (including full and/or partial ROM images) should be searched for and loaded into the emulation engine. All other irrelevant files in the directory should be ignored.
• When a pattern is specified (or, by default, any available ROM set is searched for), the CM-32L ROMs should still have higher priority that MT-32 ROMs, yet higher control ROM version should always win if multiple are available.

Upon successful startup, the tool should indicate the machine model, for which the ROM files have been loaded and are being used.

cmake error "ON" "OR" "ON" "OR"

Last commit causes a cmake error
83a6f3e#diff-65d9466fa9d035a02960824036649c2eb4905db6dead1069881c4bffcf6d169d

Error:

CMake Error at mt32emu/CMakeLists.txt:13 (if):
  if given arguments:

    "ON" "OR" "ON" "OR"

  Unknown arguments specified

If we go back to the original state, the compilation passes.
if(${munt_WITH_MT32EMU_SMF2WAV} OR ${munt_WITH_MT32EMU_QT})

My system: GNU/Linux - Debian Unstable, cmake 3.18.4

More of a question to the creator.

Hi, am more in wanting to let the creator aware of there is another roland project going on, its an attempt of recreating the roland sound canvas called emusc, do you think some of the munt project code can be used in that particular software? along with the ui.

DosBox + Munt hangs Toshiba Satelitte L670 (AMD HDMI?) audio driver.

DosBox + Munt hang the audio driver of this Laptop which is very annoying and requires many resets.

The hang of the audio driver/default IME is most likely caused when switching between window and full screen and also on exit.

OS Is Windows 7 Home edition.

It also prevents Firefox from playing any videos and it will also crash firefox and any other audio application until a reboot is done.

Tried to disable audio device and tried to restart audio service but this doesn't work/help. Very strange windows issue/driver issue.

I am willing to run a debug build of either dosbox or munt to try and diagnose this problem.

AMD HDMI driver is probably culprit, the same behaviour is witnessed when playing Predator Hunting Ground.

Sometimes 7.1 configuration also has to be re-done plus volume adjustment cause it goes to 100%.

All in all this is a major pain in the ass to deal with, fortunately I configured the laptop to reboot fast otherwise this would be an insane problem.

Improve X desktop integration

As suggested by @IlyaIndigo in #54, the desktop file should advertise more categories which are relevant to mt32emu-qt. Namely, Categories=Qt;AudioVideo;Midi; should be more appropriate.

Also, as we only have bitmap icons, we should install more of them under path /usr/share/icons/hicolor/NxN/apps/ for better desktop experience and avoid relying on the system to scale one icon.

Add support for bitwise ROM dumps to the UI application

Since (#44), mt32emu supports bitwise ROM dumps (a.k.a. partial ROM images), those can now be identified, loaded and merged for use by the synth engine.

However, the ROM selection dialog does not provide a possibility to select more than 1 ROM file of each type (control / PCM), so that only the full ROM images are effectively supported.

Additionally, only two configured ROM filenames are used internally and stored in the application settings. Instead, the max of 4 filenames must be supported.

mt32emu_alsadrv: MIDI port doesn't set SND_SEQ_PORT_TYPE_MIDI_GENERIC

In a project of mine, I detect available MIDI ports by testing for the SND_SEQ_PORT_TYPE_MIDI_GENERIC flag:

https://github.com/realnc/dosbox-core/blob/c106dc49b1a15ed1b04717e3e5a29b39ea9ac9cd/libretro/midi_alsa.cpp#L40

This makes sure that non-MIDI ports won't get listed as choices to output MIDI to. Like the "System Timer" port.

However, when running mt32d, the MT-32 ports get registered with ALSA but they don't have the SND_SEQ_PORT_TYPE_MIDI_GENERIC flag set. So they get skipped.

That flag is documented as "This port understands MIDI." So I believe mt32d should set that flag on the ports it creates.

For now, I can hard-code a workaround for ports named MT-32. But I think the proper fix is for the ports to actually have the SND_SEQ_PORT_TYPE_MIDI_GENERIC flag set, since they do understand MIDI messages.

Edit:
I can also test for SND_SEQ_PORT_TYPE_MIDI_GM/GS/XG/MT32/GM2, which the driver correctly sets. But I believe SND_SEQ_PORT_TYPE_MIDI_GENERIC is a catch-all for all of these for when an application doesn't actually care about which MIDI standard the port supports and all it cares about it whether MIDI can be sent to it or not.

Static lib is not installed when LIB_INSTALL_DIR is specified

libmt32emu.a is not installed correctly when -DLIB_INSTALL_DIR= is used:

cd mt32emu
mkdir build
cd build
cmake -DCMAKE_INSTALL_PREFIX="/tmp/mt32" -DLIB_INSTALL_DIR=lib -Dlibmt32emu_SHARED=OFF ../
make install

[snip build log]

Install the project...
-- Install configuration: ""
-- Installing: /tmp/munt/mt32emu/build/lib/libmt32emu.a
-- Installing: /tmp/mt32/include/mt32emu
-- Installing: /tmp/mt32/include/mt32emu/config.h
-- Installing: /tmp/mt32/include/mt32emu/c_interface
-- Installing: /tmp/mt32/include/mt32emu/c_interface/cpp_interface.h
-- Installing: /tmp/mt32/include/mt32emu/c_interface/c_types.h
-- Installing: /tmp/mt32/include/mt32emu/c_interface/c_interface.h
-- Installing: /tmp/mt32/include/mt32emu/Synth.h
-- Installing: /tmp/mt32/include/mt32emu/SampleRateConverter.h
-- Installing: /tmp/mt32/include/mt32emu/ROMInfo.h
-- Installing: /tmp/mt32/include/mt32emu/MidiStreamParser.h
-- Installing: /tmp/mt32/include/mt32emu/FileStream.h
-- Installing: /tmp/mt32/include/mt32emu/File.h
-- Installing: /tmp/mt32/include/mt32emu/Types.h
-- Installing: /tmp/mt32/include/mt32emu/Enumerations.h
-- Installing: /tmp/mt32/include/mt32emu/globals.h
-- Installing: /tmp/mt32/include/mt32emu/mt32emu.h
-- Installing: /tmp/mt32/include/mt32emu.h
-- Installing: /tmp/mt32/lib/pkgconfig/mt32emu.pc
-- Installing: /tmp/mt32/share/doc/munt/libmt32emu/AUTHORS.txt
-- Installing: /tmp/mt32/share/doc/munt/libmt32emu/COPYING.txt
-- Installing: /tmp/mt32/share/doc/munt/libmt32emu/COPYING.LESSER.txt
-- Installing: /tmp/mt32/share/doc/munt/libmt32emu/NEWS.txt
-- Installing: /tmp/mt32/share/doc/munt/libmt32emu/README.md
-- Installing: /tmp/mt32/share/doc/munt/libmt32emu/TODO.txt

[Question] Interested in LCDd support?

A while ago I made a MIDI synth compiling munt for an RPi 3B+ and since it was a dedicated one I ended up wiring up a 20x4 LCD and implementing some crude support for LCDd/lcdproc.

Was rummaging around and dusted off the code recently after re-adding an LCD to my desktop - so I wanted to ask if there's interest in my taking a little time to polish it some more and make a pull request. It'd be a neat feature to have upstream but of course it requires someone willing and able to maintain it.

Currently hard-wired to expect 20x4 but obviously part of the polish would be giving it the ability to adjust for whether it's a 16/20x1/2/4.

Picture: (Ignore the LCD smudges, it's not a particularly great LCD and the camera doesn't capture it well. Looks much better in person)

Add general support for implementation of emulated MT-32 LCD

Currently, libmt32emu only provides limited possibility for a consumer application to implement an emulated MT-32 LCD. There are several pretty low-level callbacks in ReportHandler class available, so that rather a good knowledge of MT-32 internals is required to facilitate emulation of the MT-32 LCD further.

Instead, the library shall hide the complexity from the consumer application by providing a few high-level easy-to-use functions and callbacks, as well as implementing a good deal of common code that is specific to MT-32 LCD.

From the functional PoV, the library shall:

• largely emulate the internal state of the MT-32 LCD unit (leaving aside some minor detail like usage of certain special characters, cursor blinking, etc.);
• provide access to the text representation of the current state of the emulated LCD for the consumer application;
• notify the consumer application about each change of the LCD state.

Providing a function for rendering the text representation of the LCD state to some graphical format does not seem feasible and reasonable due to variety of available LCD hardware implementations, yet the widely used facilities of communication with the hardware LCDs like LCD Smartie and lcdproc currently foresee displaying textual data only via their standard API.

Per-part volume override, blocks #77

To implement any sensible behaviour in feature #77, the library should provide a way for the client application to configure volume levels for each part and ensure that they are preserved regardless of other processed MIDI commands. In fact, a similar function wrt. the reverb settings is already implemented, however they do not get restored once the "reverb overridden" mode is switched off. In contrast, reverting the volume set on a part by MIDI messages when the user disables the muting on that part seems very useful. The emulated synth hence should merely ignore the effect of certain MIDI messages (e.g. NoteOn (when muted), the Volume controller and the Patch temp SysEx writes) and apply the override as long as it is enabled.

Add a command-line option for resetting application settings

It should be possible for the user to revert the application settings to the factory defaults, even in case the application no longer starts normally, so it may become challenging for the user to adjust settings any longer.

This is sometimes done by adding a "purge" function to the uninstaller. However, it is not a convenient option if the user wants to continue working with the application. Additionally, if the application is installed system-wide, the uninstaller typically fails to purge settings for all the users who have them created, and performs the cleanup for the current user only.

Hence, it should likely be a command-line switch that the application parses and handles early, e.g. before attempting to start MIDI and audio processing, which might block normal startup in some rare cases (albeit, such bugs deserve a separate issue).

Dosbox r4479: MIDI:Can't find device:mt32

Hi.

I used your r4479 patch and compiled Dosbox r4479, but when using "mididevice=mt32" I get:
"MIDI:Can't find device:mt32, finding default handler.
ALSA:Client initialised [128:0]
MIDI:Opened device:alsa"

Cheers,
Emanuel

Problem writing reverb settings over SysEx

I've been successful writing to both the display and the master volume using SysEx from Cubase v3.1 on the Atari ST (emulated in STEem, an Atari ST emulator for Windows).

However, when I try to write to the reverb registers, nothing happens. I'm using the exact same process as when I write to the display and the master volume (and the master volume is even in the same address space as the reverb registers).

I'm starting to suspect this might be an issue with Munt itself.

For reference, the string I'm using to set master volume to 0 is (all hex):
f0,41,10,16,12,10,00,16,00,5a,f7
...and to set it to 100:
f0,41,10,16,12,10,00,16,64,76,f7
(you will notice the "data length" byte (a0 as the second byte in both strings above) is missing, but Cubase adds it in automatically)

String I'm using to try to change reverb mode to Plate reverb:
f0,41,10,16,12,10,00,01,02,6d,f7
...and I've tried other values for the data byte (02) too, but it made no difference.

I even found a forum post where someone claimed success changing to Tap delay with max volume and time using the three following SysEx strings, but they do nothing here either:

F0,41,10,16,12,10,00,01,04,6B,F7
F0,41,10,16,12,10,00,02,08,66,F7
F0,41,10,16,12,10,00,03,08,65,F7

Per.

Add support for the 3rd-gen MT-32 compatible devices (such as CM-500 and LAPC-N)

The 3-rd gen devices are very close in behaviour and features to the 2nd-gen ones (MT-32 new, CM-32L, etc.), although they are based on different hardware. Notably, they utilise a newer, more powerful MCU 80C198. However, this fact reveals itself in a notable quirk known as "fast vibrato". Additionally, they use another control ROM version that has been updated to adapt for the hardware changes.

[Enhancement] Request to add munt support in DosBox-X

Request to add munt support in DosBox-X

https://github.com/joncampbell123/dosbox-x

Lag when period size required by driver is larger than requested

I have a setup where I route all audio through jack. As such I use the alsa jack plugin to get alsa apps to use it for audio output.

I was trying to "play" munt via a midi keyboard and found that I was unable to make the latency acceptable. Whatever settings I gave it seemed to get multiplied by some factor - attempting to force a latency of 40ms gave an actual latency of ~300ms. This was happening in both the cmdline prog mt32d and with mt32emu-qt.

I added some code to dump alsa hw params and found that the actual period size used, as returned by snd_pcm_hw_params_get_period_time, was ~5ms. This was correct given I had selected a period size of 256 frames at 48000Hz in jackd.

However the code appears to ask for a period size of ~0.7ms and assumes it gets what it asks for. Also it looks like the buffer size calculations assume a period size, so when it is not what is expected, the effect is that the latency is not what is asked for.

Add support for bitwise ROM dumps to the Windows MME driver

Since (#44, #56), mt32emu-qt supports bitwise ROM dumps (a.k.a. partial ROM images), those can now be identified, loaded and used by synths.

Should such partial ROM images be configured in the default synth profile, the Windows MME driver shall be able to loads those as well.

Additionally, the driver should not fallback to loading ROM files from the system-wide directory C:/WINDOWS/SYSTEM32/ that may well be not-existent at all. Instead, in case the ROM directory is not stored in the UI application settings, the driver shall fallback to using the implied default path roms in the current user profile, similarly to how the UI application works.