Could dosbox include the mt32 'dynamic linking' patch?
It's really, really tiring to start up munt before running games that i configured to use mt32 /don't even know what those are after a while.
This is not a DOSBox topic.
Besides, using Munt's GUI is not more annoying than setting up your *real* synth.
Anyway, the patch is included in Ykhwong's build.
Setting up Munt is no big deal. One the driver is installed, all that is required is to either set the system to use Munt for the MIDI device or set it in the dosbox.conf. I wrote an installer for the driver that worked on x64 that I gave the script to KG upon request, but nothing ever came of it. I assumed that it was, at least in part, because emphasis was being shifted to the QT app.
If you can't be bothered with setting up the driver, just use the Qt app and be happy. If you really need a special build of DOSBox, there is always sergm's DOSBox build https://github.com/sergm/munt_devel/downloads
so is the windows driver on par with all the other implementations of mt32 emulation? I think it would be easiest to just set it in windows and select the appropriate mt32 option in game (assuming that would work). You wouldn't need special builds of dosbox for that, correct?
How is updating of the driver handled? What's the process?
I'm using linux... exclusively. BTW, dosbox doesn't compile with ubuntu's sdl otherwise i wouldn't even tried to mention this. I'd just build it and place it on my ppa.
Drivers? WTH... i don't want to install weird linux midi drivers and mess with ports to use dosbox. Please, some sanity, just do what scummvm does and detect the presence of libmunt.
Be 'happy' i need to start a totally unrelated program whenever i want to play a game (the only thing i use munt for) i don't remember i configurated to use mt32?
*place spartan madness gif here*
BTW, did Antara ever get a full install Collector? I'm the same guy that wanted it (and the same guy that hacked that pitiful nocd for QFG5)
Linux, of course is another issue as far as the driver goes. If I am wrong, sergm can correct me, but I believe that portability is one of the main reasons that emphasis has shifted to the QT app from the driver. That and the app emulates the LED display as well.
No. I never got around to Antara. It has been a while, but I am assuming that you know of the installer that jafa did, but without a full hard drive install, but this would be a topic for another thread. I don't want to hijack the Munt thread.
I have to say that I prefer the integrated munt as well, since you can just set this up per game once and be done with it 😉
SCO: it sounds as if you installed the wrong SDL. If you install SDL 1.2.15 and the 1.2.15 development package, Dosbox should compile. You may need a different thread for that as well.
wrote:dosbox doesn't compile with ubuntu's sdl
Sounds weird for me too 😒 The only problem with building DOSBox on Ubuntu I've ever experienced was adding "#include <stddef.h>" row.
Though, I don't think having a dl'ed munt version would bring some advantages. I see no problems with configuration of a MIDI port for using with munt just like you do for any external unit. Moreover, h/w units appear to be more requiring in configuration (you know, all those delays, port sharing, etc.). Anyway, the final decision whether to include munt (either statically or dynamically linked) is left for DOSBox team.
BTW, Qt-app is designed to be always running in the background showing just an icon in the system tray, so you don't even need to start it before launching every game. 😀
Ok i'm trying the 'apply patch in launchpad recipe to dosbox svn fork, profit' scheme.
However, i just realized: the patch is not the complete emulator right? It depends on libmunt/mt32emu being accessible... right? And libmunt/mt32emu doesn't appear to be on the the ubuntu repositories.
Correct. It seems KG doesn't want to maintain a ppa for it, so you are supposed to compile and install the lib yourself.
can you give a repository with the 'best' uptodate munt? If i'm doing a ppa, might as well build munt.
https://github.com/munt/munt is the main repo. We are trying to keep it stable and at least compilable. Though, no recent releases made so far. 😒
What are the munt dependencies (i hope they are debianized?)
Actually, IIRC, GLIB and CMAKE (and make/g++ of course). The entire build process is controlled by CMAKE, so don't hesitate to check CMakeLists.txt
EDIT: GLIB is required for smf2wav only.
Debian changelogs are a problem (they are used to name packages too).
You repo doesn't appear to have one, so is there any possibility of transforming the git log to a debian one? If you use tags to mark releases i could use the last tag as a main version number (actually using that would be a hell of a lot fragile though).
If not, i will create a almost empty dummy and use simply the revision number as the package version (a snapshot obviously).
Oooooor, i could get 'smart' and compile mt32emu as a part of the dosbox project... problem would be to make the launchpad recipe import the code from the repo. Not sure if a good idea
BTW, i created a 'munt' project on launchpad - i needed it to import the repository to build it on launchpad, haven't packaged anything:
https://launchpad.net/munt
if you want to become the project owners (it's just a mirror of the git, but should you manage to build a recipe, and ppa it could be a one stop place to get munt for ubuntu users) tell me about it (would have to investigate how to do it though).
Also autotools complains when building munt:
"E: dosbox source: ancient-autotools-helper-file munt/portaudio/bindings/cpp/build/gnu/config.guess 2001-10-05"
http://lintian.debian.org/tags/ancient-autoto … elper-file.html
I can make it go away by including a autotools dependency on the control file, which probably isn't the right solution in cmake
Where in the mt32emu project is the default rom location being specified (i want to change it to ~/.dosbox obviously).
From a cursory grep... it doesn't appear to be specified by itself?!?
Well, maybe i can debianize munt after all, if i have to change the code to use it on dosbox.
The synth searches for ROM files using SynthProperties.baseDir, but in that DOSBox patch it is set to NULL and the current directory is used. It's quite alright for win* since you just place ROMs into DOSBox's dir. But it's really awkward in *nix envs.
But really, why don't create a specific topic about munt building or even making a deb? 😉
Yes, i thought of that, but it's not so good for linux (/usr/bin/). I guess the better way is to put it on ~/.dosbox in this case.
If i have more doubts i will start a new thread.
