VOGONS


Munt Reloaded - Development

Topic actions

Reply 740 of 965, by MusicallyInspired

User metadata
Rank Oldbie
Rank
Oldbie

The MT-32 precedes the GENERAL MIDI standard, not MIDI. It runs on MIDI!

Yamaha FB-01/IMFC SCI tools thread
My Github
Roland SC-55 Music Packs - Duke Nukem 3D, Doom, and more.

Reply 741 of 965, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Something strange with my dosbox build with dosbox mt32. It's the clean linux build off the ppa with nothing else.

Dosbox current svn on max cycles runs Azrael's Tear ok. I fiddled with and without dos32a, running off the cd or running from the drive after copying the missing files and completed the game that way (but i'm currently testing the unmodified game mounted with a iso and installed normally).

Mt32 build, regardless of turning off MIDI with (the game is not configured to use mt32 or gus, but it doesn't matter), or near doubling dosbox memory from 16 to 31.
[gus]
gus=none

[midi]
mpu401=none
mididevice=none
midiconfig=
mt32.romdir=

in the conf file, which i'd expect would nuke the emulation from even starting always eventually manages to crash dosbox (not the game only, dosbox), and ouputs:
terminate called after throwing an instance of 'char*'
Aborted

Any of you have any clue?

edit: this also happens with system shock portable. System shock portable is a good test because it's free.
https://www.systemshock.org/index.php?topic=211.0
In in linux with a dosbox svn compiled with your mt32emu dosbox patch without modifications and it crashes with that when i mount c . and call cdshock.

Last edited by Serious Callers Only on 2015-07-30, 05:40. Edited 1 time in total.

Reply 744 of 965, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I also don't think it's the same bug. Because that one can be worked around by setting cycles these in azrael's tear (eventually) and in system shock cd (immediatly) crash the game regardless of cycles (i tested cycles=200 with cdshock now that i had a repeatable 'exec' testcase just to be sure). It took a few seconds but it crashed with the same message. And besides, they crash dosbox, not blackscreen it.
The message passes a bit too fast to read inside the dosbox screen. Outside it's always the same.

Last edited by Serious Callers Only on 2015-07-30, 05:46. Edited 1 time in total.

Reply 746 of 965, by Serious Callers Only

User metadata
Rank Member
Rank
Member

I'd be relieved if you could reproduce it with a compiled exec from yourself and systemshock portable. Just to be sure it's not something weird in my compile options (but it's just -O3) or my system.

it could also be a dosbox svn bug, i tested the 'not crash' case with 0.74.4 from the ubuntu repository instead of using the svn without any patch at all. Maybe that's even likely, i need to check.

edit: that's right. It's dosbox svn.
edit2: or maybe not. I tested with a new unzip of SSP and right now i can only get it to hang on start not crash. Maybe

edit: it's pretty strange. Unmodified SSP may started with dosbox svn:
start normally
hang forever (sometimes)

What i can't do is to get it to crash again on start doh. Maybe something changed in the conf file.

Reply 747 of 965, by Serious Callers Only

User metadata
Rank Member
Rank
Member

Uh, now i tried the dosbox svn on azrael's Tear with until i made it crash. And then i tried the same executable on systemshock SSP and it NOW crashes all the time again.
This is very strange. Is there anything persistent that can happen? It's not the .dosbox/dosbox-SVN.config because i moved it.

Reply 752 of 965, by johnnynismo

User metadata
Rank Newbie
Rank
Newbie

There was talk in the past about making MUNT for Android. This is an appealing idea to me as I could use a Roland UM-One USB cable with my phone and use the phone as a MIDI device for my retro gaming PC. Did anything ever become of this idea?

Reply 753 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Not sure. It looks like the primary Android port of DOSBox has Munt built-in, and it runs okay on my Nexus 7 2012.

Can munt operate as an ALSA sequencer on Linux? The source repo says something about it being an obsolete feature?

Reply 754 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie
HunterZ wrote:

Not sure.

Unfortunately, Munt's become quite a mess of code by now, so let me make a little clarification.
The library mt32emu - the core synth engine - is always intended to be portable, and thus it doesn't rely on system-specific features. The idea is to acquire particular system services from clients via some abstractions. This means, it is unlikely for the library to fail a build on a particular system. However, the build system it currently relies on (CMake) supports a limited set of environments and specifically doesn't offer an official way to build applications for Android by now.

Nevertheless, this doesn't seem to be a big problem by now, as, while in development stage, we published the statically linked library only, merely keeping source-level compatibility. This situation provokes other developers to simply add mt32emu sources (often patched) to their projects, ending up to be a pain upon updates. I guess I won't be too wrong assuming that every DOSBox build with munt-based MT-32 emulation has the library sources absorbed.

It looks like the primary Android port of DOSBox has Munt built-in, and it runs okay on my Nexus 7 2012.

That sounds inspiring! (meaning that even if some compatibility problems exist, they are very solvable)

Can munt operate as an ALSA sequencer on Linux? The source repo says something about it being an obsolete feature?

As you know, aside from the core library, munt also provides a featured Qt-based UI application at this point. Fortunately, Qt5 officially supports Android as a target platform, so Android build is definitely on it's way, be sure. We also keep the historical ALSA-only "driver" for those who don't want the Qt-app for some reason. But as it looks limited enough, it should be thought of as obsolete and not recommended for use.

Side note: as promised, I added a more portable C-compatible API for the core library, and it's being polished up atm. This will end up with a shared object looking like a regular commonly used lib in *NIX systems. There is even a possibility to build a COM-ish .DLL file (e.g. for loading at run-time). Perhaps, this makes the library more suitable to use.

Reply 755 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Thanks. My ALSA question was meant to be separate from the Android discussion, though. I've been using Ubuntu MATE on my old gaming laptop lately, and would like to know if it is possible to set up a system-level Munt (like the driver version in Windows) so that I don't have to figure out how to patch it into everything that I want to use it with.

How does the Qt app interface with other MIDI applications in Linux?

Reply 756 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Added short info about supported MIDI interfaces in mt32emu-qt (hopefully that is quite a stable thing now):
https://github.com/munt/munt/commit/c00d26a0e … d90ff9c20bc6d77

Not sure though, whether it compiles on your system. Qt versions below 4.8 may require code patching in accordance. I think ALSA driver compiles at least.

Reply 758 of 965, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

So I'm trying to build mt32emu-qt (well, all of munt actually) on Ubuntu MATE 15.10 x64, and I'm having problems:

cmake said my version of Qt was unsuitable when I installed Qt5 (5.4.2?) from the Ubuntu repos. I removed it and installed Qt4 (4.8.6) from the Ubuntu repos, and cmake finally worked.

When I tried to build, however, I get the following error:

[ 25%] Built target mt32emu
[ 32%] Built target smf
[ 34%] Built target mt32emu-smf2wav
[ 35%] Automatic moc for target mt32emu-qt
[ 35%] Built target mt32emu-qt_automoc
[ 37%] Building CXX object mt32emu_qt/CMakeFiles/mt32emu-qt.dir/src/QSynth.cpp.o
/home/ben/projects/munt/mt32emu_qt/src/QSynth.cpp: In member function ‘virtual void QReportHandler::printDebug(const char*, __va_list_tag*)’:
/home/ben/projects/munt/mt32emu_qt/src/QSynth.cpp:39:25: error: ‘vasprintf’ is not a member of ‘QString’
qDebug() << "MT32:" << QString::vasprintf(fmt, list);
^
mt32emu_qt/CMakeFiles/mt32emu-qt.dir/build.make:336: recipe for target 'mt32emu_qt/CMakeFiles/mt32emu-qt.dir/src/QSynth.cpp.o' failed
make[2]: *** [mt32emu_qt/CMakeFiles/mt32emu-qt.dir/src/QSynth.cpp.o] Error 1
CMakeFiles/Makefile2:230: recipe for target 'mt32emu_qt/CMakeFiles/mt32emu-qt.dir/all' failed
make[1]: *** [mt32emu_qt/CMakeFiles/mt32emu-qt.dir/all] Error 2
Makefile:136: recipe for target 'all' failed
make: *** [all] Error 2

Any idea what I'm doing wrong?

Edit: Looks like the problematic code was added in the last commit. I reverted those changes in my local copy and it builds fine.

Reply 759 of 965, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Quite possible, as I use Qt 5.5.1 in development (and this function was introduced in Qt 5.5 as the doc says), I'll fix.
I guess that warning about unsuitable Qt version is caused by Qt4 plugin that searches for Qt first. But it should build normally with Qt5 nevertheless. To get rid of this warning, you can set mt32emu-qt_WITH_QT5 to true when configuring cmake build.