VOGONS


First post, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Hi everyone.

I'm happy to announce that munt 2 is out at last and becomes available for downloading shortly at our Source Forge page as usual. Most annoying bugs were fixed and some interesting new features were added. The complete list of notable changes can be seen here.

Of course, we're looking forward to your feedback.

Reply 2 of 16, by OmerMor

User metadata
Rank Newbie
Rank
Newbie

And for the lazy, here're the release notes:

2016-10-22: 2.0.0 released.

The distribution include following components:
* libmt32emu - C/C++ sysnthesiser library
* mt32emu_qt - main sysnthesiser application
* mt32emu_win32drv - MIDI driver for Win32 with helper setup utility
* mt32emu_smf2wav - console tool for converting MIDI files to Wave files using the mt32emu library

Folders:
* Windows - Windows binaries
* Ubuntu-16.04 - .deb packages for the recent Ubuntu release

Files:
* munt-2.0.0.tar.gz - source distribution

Notable changes:

mt32emu
=======

* Introduced support for sound groups. Callback ReportHandler::onProgramChanged() now supply correct sound group name
instead of just the index of the timbre bank.
* Reworked ControlROMFeatureSet. MT-32 GEN0 quirk "Pitch Envelope Overflow" exploited in Colonel's Bequest timbre "Lightning"
is now emulated when loading one of control ROMs v.1.04-1.07.
* Improved current loose implementation of SysEx handshake communication. Specifically, disabled the check for partial
activity, as that caused SysEx messages to be ignored without any feedback.
* API and build changes:
- minimum required version of Cmake raised to 2.8.12;
- clarified existing C++ API, mt32emu.h no longer used internally but intended for clients;
- encapsulated MT32EMU_USE_FLOAT_SAMPLES definition, API provides rendering in both 16-bit signed integer and float
formats, sample conversion applies implicitly when needed;
- introduced C-compatible API as a facade, that allows using the library with programs written in other languages
as well as provides for consistent well-defined ABI for the library as a shared object;
- C-compatible API also involves COM-like interfaces to simplify usage of the library as a plugin loaded in run-time;
- three new build options libmt32emu_SHARED, libmt32emu_C_INTERFACE and libmt32emu_CPP_INTERFACE intended
to configure whether to build a statically or dynamically linked library, whether to include C-compatible API,
and whether to expose C++ classes (old-fashioned compiler-specific ABI).

mt32emu_qt
==========

* Updated mt32emu library to version 2.0.0.
* Added support of ALSA raw MIDI ports in ALSA MIDI driver. Configuration option mt32emu-qt_WITH_ALSA_MIDI_DRIVER
renamed to mt32emu-qt_WITH_ALSA_MIDI_SEQUENCER for consistency, and is now set to TRUE by default on Linux systems only.
* Added handling of fragmented SysExes in ALSA MIDI driver.
* Improved CoreAudio driver: CoreAudioStream no longer renders data in the GUI thread, a dedicated internal AudioQueue thread is used instead.
* Improved MIDI timing calculations. Introduced MIDI latency autodetection mode (initiated by setting MIDI latency to 0).
* Added build option mt32emu-qt_WITH_DEBUG_WINCONSOLE. It controls whether a debugging console is shown on Windows.
* Fixed a bug in LinearResampler that may cause incorrect output at beginning of each audio block.
* Introduced full-featured internal resampler. The intention is to make resampling less demanding than libsamplerate requires
yet to reduce the processing delay libsoxr introduces. That's achieved by taking advantage of oversampled output produced
by analog circuit emulation engine and using efficient elliptic low-pass filter instead of FFT-based FIR.
* Added build option mt32emu-qt_WITH_INTERNAL_RESAMPLER. It controls whether to use internal resampler or try to find an external library.
* Added support for Qt5.
* Improved support for 64-bit Windows.
* Improved support for Cygwin, enabled native Windows MIDI and wave audio API.
* Improved LCD emulation: when setting standard patches, proper sound group name is shown.
* Introduced pause function in MIDI player for convenience.
* Introduced a possibility to synchronously record audio output from a synth to a file along while listening.
* About window now shows target arch and used version of Qt library.

mt32emu_win32drv
================

* Fixed possible crashes when reloading settings to the internal synth upon MIDI port re-opening in some cases.
* Updated mt32emu library to version 2.0.0.
* Added support for mt32emu_qt settings version 2.

Reply 3 of 16, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie

Thanks Sergey for the great work. So far so good!

Incidentally, I've recently received a couple of U110 PCM cards and couldn't help wondering about the state of CM-64 emulation. Is this planned on the Munt roadmap?

Ryzen 2600X 4.2 GHz | Radeon RX 6650 XT 8 GB | DDR4 16 GB | Win10-64 Pro

Reply 4 of 16, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

As CM-64 has two boards inside, I'd split the issue, Kaminary (just for simpicity) 😀

If it comes to CM-32L part, I hope the emulation is close enough and most probably won't advance any more. When we get the MCU modelling engine, it well may improve but we are certainly not there atm. I'm not too sure about the CM-32P part. Taking into account the munt scope, it looks like improving emulation accuracy of old MT-32 units is more important. This is the top goal so far, and when it's been done, we may return to this question (if time permits, yeah...).

But ironically, both KingGuppy and I have exactly CM-64 😉

Reply 5 of 16, by DOSUserDude

User metadata
Rank Newbie
Rank
Newbie

* Added build option mt32emu-qt_WITH_DEBUG_WINCONSOLE. It controls whether a debugging console is shown on Windows.

I noticed your default Windows distribution no longer has the systray UI console option as it always has in the past - apparently you compiled the default distribution without it.

Wouldnt the better solution be to include the console option in the default build, but then make the display of it optional via command line parameter?

Isn't that what DOSBox/SCUMMVM/et al do?

Doesn't even have to be enabled by default - but not having the option at all in a default distribution, changed from all previous default distributions - and without notification of the change - seems a bit shortsighted.

Reply 6 of 16, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Great work! Thanks for your persistence!!!

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 10 of 16, by lukeman3000

User metadata
Rank Member
Rank
Member

Hi sergm -

I posted in MT-32 about this but thought I'd post here as well since it seems relevant.

Using DOSBox SVN r4006 ECE build, I get what seems to be some kind of distortion when using MT-32. A comparison between vanilla DOSBox/external MUNT and r4006 ECE build can be seen here.

The first version heard is that of vanilla DOSBox and external MUNT, while the second is r4006 ECE build with integrated MUNT.

All settings are default in both scenarios... any ideas?

Reply 11 of 16, by SedrynTyros

User metadata
Rank Member
Rank
Member
lukeman3000 wrote:
Hi sergm - […]
Show full quote

Hi sergm -

I posted in MT-32 about this but thought I'd post here as well since it seems relevant.

Using DOSBox SVN r4006 ECE build, I get what seems to be some kind of distortion when using MT-32. A comparison between vanilla DOSBox/external MUNT and r4006 ECE build can be seen here.

The first version heard is that of vanilla DOSBox and external MUNT, while the second is r4006 ECE build with integrated MUNT.

All settings are default in both scenarios... any ideas?

Does the distortion exist if you use the r4000 build I gave you? You may remember that I mentioned the DOSBox developers rewrote some of the sound code in the last 5 or 6 SVN code changes.

Reply 13 of 16, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

Just a quick question concerning DOSBox: It seems MT32 is set as the new default MIDI device when I apply your patch. Can this be changed (easily) and if so, how?

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 14 of 16, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Yes, sure. Just find the rows

#include "midi_mt32.h"
static MidiHandler_mt32 &Midi_mt32 = MidiHandler_mt32::GetInstance();

in src/gui/midi.cpp and reorder them relative to the other MIDI drivers.

Reply 15 of 16, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote:
Yes, sure. Just find the rows […]
Show full quote

Yes, sure. Just find the rows

#include "midi_mt32.h"
static MidiHandler_mt32 &Midi_mt32 = MidiHandler_mt32::GetInstance();

in src/gui/midi.cpp and reorder them relative to the other MIDI drivers.

Thank you very much, worked perfectly! 😀

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 16 of 16, by Malik

User metadata
Rank l33t
Rank
l33t

I'm a great fan of MUNT. It made me sell off my CM-32Ls, MT-32s and even the CM-500 and my dear-old LAPC-I !!!

(I am still keeping a Roland MT-32 and SC-55 MKII for vintage sake)

The trade off that comes with it - portability - even in my Windows 10 Dell Tablet is worth it.

The ability to play DOS classics, especially Sierra games with MUNT on my tablet anywhere, anytime, more than makes up for the loss of not having tied down to the desktop with additional power adapters and wires and so on.

Thanks a lot, sergm!

5476332566_7480a12517_t.jpgSB Dos Drivers