Munt Reloaded - Development

Developer's Forum for discussion of bugs, code, and other developmental aspects of the Munt Project.

Re: Munt Reloaded - Development

Postby KainXVIII » 2017-7-30 @ 19:12

Nice!
PS - but now its even more difficult to know which rom files to use with different games to play it perfectly :dead:
User avatar
KainXVIII
Member
 
Posts: 221
Joined: 2015-5-20 @ 15:04
Location: Yaroslavl

Re: Munt Reloaded - Development

Postby Falcosoft » 2017-9-06 @ 21:06

Hi Serg,
A Greek user has reported that he cannot load ROM files. I have checked and the problem seems to be that the path where he tried to load the ROM files from contained Greek characters.
In Munt's code this part gives a MT32EMU_RC_FILE_NOT_FOUND error when any non-Latin 1 character is found in the path even if the code page (System locale) is set properly:
Code: Select all
FileStream *fs = new FileStream;
   if (fs->open(filename)) {
      if (fs->getData() != NULL) {
         rc = addROMFile(context, fs);
         if (rc > 0) return rc;
      } else {
         rc = MT32EMU_RC_FILE_NOT_LOADED;
      }
   } else {
      rc = MT32EMU_RC_FILE_NOT_FOUND;


The file stream eventually calls mbstowcs_s() function for multibyte to widechar conversion.
I have compiled Munt's library with VC++ 2005 and there seems to be a problem with VC++'s mbstowcs_s() function:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/ced3292b-69de-4ca5-9246-762d3ff014c0/ifstream-s-mistake-in-vc8-correct-in-vc71?forum=vcgeneral
Here it is suggested that setlocale(LC_CTYPE, ""); should be called otherwise the mbstowcs_s() function will use the "C" locale. I do not know if it is a cross platform solution so any other solution is welcome (the suggested solution works anyway).
Thanks in advance.
User avatar
Falcosoft
Member
 
Posts: 394
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Munt Reloaded - Development

Postby sergm » 2017-9-07 @ 18:15

Oh, right. I'll push a fix shortly...
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2017-9-08 @ 05:44

Ah, I see. This seems to be a problem with old MS C runtime. I can reproduce it also with VC 2008. Anyway, I think it's better to fix it at the application level rather than hack the library and change global locale.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Falcosoft » 2017-9-08 @ 11:42

It's only possible to fix it at the application level if the application itself uses the same C runtime as the library. Unfortunately it's not possible in my case since the host application does not use any C runtime (it is written in Delphi). So I think at least a compile time conditional switch would be necessary at the library level that defines whether the library should override the C locale or not.
(BTW I could reproduce this problem with Win32 Munt binary releases so it seems the Qt application is affected too.)
Thanks.
User avatar
Falcosoft
Member
 
Posts: 394
Joined: 2016-5-21 @ 13:46
Location: Pécs, Hungary

Re: Munt Reloaded - Development

Postby sergm » 2017-9-08 @ 12:06

OK, will test it thoroughly when built as a shared library. And yes, both mt32emu-qt and mt32emu-smf2wav Windows builds are affected but due to another reason (they rely on support of UTF-8 which MSVC never provided).
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development - Synth X tabs check / refresh issue

Postby 95DosBox » 2017-9-09 @ 17:26

Sergm here is a Possible bug I noticed:

When running DOSBOX with Munt (mt32emu-qt.exe) not loaded and not loaded minimized, then after starting the DOSBOX game with MT-32 support, then loading the Munt console (mt32emu-qt.exe), the console screen does not show the DOSBOX using Munt as a Synth X tab and thus no Synth green led status panel is available to see the effects MIDI messages.

Could Munt (mt32emu-qt.exe) autodetect when loading that previously engaged Munt synths check and show those Synth tabs? Or a Refresh Synth tabs button to update if they aren't showing up when Munt (mt32emu-qt.exe) was loaded after DOSBOX was running Munt detected games?

For example if you had say DOSBOX1: Wing Commander MT-32 running and DOSBOX2 Police Quest 3 MT-32 running. The games don't matter as long as the two DOSBOX programs are both tying up and using Munt.

If you opened up Munt (mt32emu-qt.exe) after you would see no Synth tabs present. There should be Synth 1 and Synth 2 tabs and if you were to play a MIDI file in the console it should be recognized as a Synth3 tab since the two DOSBOX sessions running Munt are and should be using the Synth 1 and Synth 2 tabs.

This isn't a major bug but just annoying but I would like to see the Windows 98 Port of Munt v2.2 done first if this bug fix will take a while to correct.
User avatar
95DosBox
Member
 
Posts: 309
Joined: 2017-5-23 @ 09:34

Re: Munt Reloaded - Development

Postby sergm » 2017-9-09 @ 18:33

95DosBox

This behaviour was deliberately chosen. The Windows MIDI driver only detects if the Qt app is running when the consumer application opens the MIDI port. It does not search actively for the Qt app when its internal synth engine is already opened. The main reason why is that the state of the internal synth is tricky to transfer to the external app reliably. For example, you may start a game inside DOSBox. The game most likely loads its specific SysExes upon launch. Then you decided to look at the LCD, so you start mt32emu-qt. If the MIDI driver detected that and switched to the external synth engine, it would start playing just like after a reset.

When planning, we considered such possible problems and decided to make the synth engine only incorporated into the GUI-based application for simplicity. We do not run a synth core service that may be shared among several applications or run in background. Neither we want to transfer any internal data from a synth engine to a GUI app like we did before (I mean that external interface existed in versions prior 1.0). Although, on Windows platform, the MIDI driver is a must, and after some thought it was allowed to be stand-alone and have an internal synth engine.

This means, the plan is to keep mt32emu-qt running in the system tray if you need it, or simply use the MIDI driver if not. Nevertheless, there is a simple way to connect a running DOSbox to a freshly (re-)started mt32emu-qt. Whenever you open the mt32emu MIDI port, the driver attempts to find the Qt app and connect. This can be done e.g. by issuing command "mididevice win32".
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Cloudschatze » 2017-10-02 @ 04:47

NewRisingSun brought an issue to my attention that would appear to be a bug, or at least an off-behavior, in some portion of the Munt code. Namely, when two or more Parts are set to receive on the same MIDI channel, only the lowest-numbered Part will actually produce sound - the other applicable Parts remain silent, and register no MIDI activity whatsoever (via the emulated LCD). This incorrect behavior does not occur with an actual MT-32 or CM-variant.
User avatar
Cloudschatze
Oldbie
 
Posts: 953
Joined: 2005-6-16 @ 14:32

Re: Munt Reloaded - Development

Postby sergm » 2017-10-02 @ 05:52

Thanks, Cloudschatze

This reminds me the issue with Death Track we have in early times described in this post. After that, we changed the part mapping so that the first part wins if more than one is assigned. Previously, the part with the highest number won. Not really sure whether any of these ways is correct though, I'll double-check.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2017-10-02 @ 06:13

Yep, both these priority-based algorithms are certainly nonsense. I'll fix.
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby sergm » 2017-10-02 @ 20:08

This is now fixed, hopefully. And thanks NewRisingSun too! :)
sergm
Oldbie
 
Posts: 734
Joined: 2011-2-23 @ 16:37

Re: Munt Reloaded - Development

Postby Myloch » 2017-11-08 @ 18:10

any of you programmers volunteer to fix munt implementation in dosbox-x?

Latest dosbox-x builds: selecting mt32 output, even with mt32 roms, sound output is broken/crap. It used to work in the past.
"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"
User avatar
Myloch
Member
 
Posts: 391
Joined: 2007-4-18 @ 22:13

Re: Munt Reloaded - Development

Postby HunterZ » 2017-11-09 @ 04:13

Myloch wrote:any of you programmers volunteer to fix munt implementation in dosbox-x?

Latest dosbox-x builds: selecting mt32 output, even with mt32 roms, sound output is broken/crap. It used to work in the past.

Why not just install the Windows MIDI driver version of Munt, and then point DOSBox at that?
User avatar
HunterZ
l33t++
 
Posts: 6055
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby Dominus » 2017-11-09 @ 05:48

That would be the easiest solution.
Other way would need you to get a develope environment up and do a git bisect to get to the point at which the git of DOSBox-x fails
User avatar
Dominus
DOSBox Moderator
 
Posts: 7333
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: Munt Reloaded - Development

Postby Myloch » 2017-11-10 @ 00:09

I would have preferred to avoid installing 2 other programs or drivers that stay in memory (I already use virtualmidisynth) but I tried installing munt and a midimapper and mt32 emulation works very well with latest dosbox-x builds (default midi output). And it's a bit more accurate than how emulation used to be in the last ykhwong build and other working older dosbox versions with mt32 internal support. I wonder how the impact is (performance-wise).
"Gamer & collector for passion, I firmly believe in the preservation and the diffusion of old/rare software, against all personal egoisms"
User avatar
Myloch
Member
 
Posts: 391
Joined: 2007-4-18 @ 22:13

Re: Munt Reloaded - Development

Postby HunterZ » 2017-11-10 @ 04:50

I don't think Munt is a memory hog. The ROMs are small. It's nothing like the memory usage required for soundfonts.

I also doubt there's a performance penalty or even noticeable lag, since MIDI was a thing in Windows at least as far back as 3.1.
User avatar
HunterZ
l33t++
 
Posts: 6055
Joined: 2003-1-31 @ 19:04
Location: Seattle

Re: Munt Reloaded - Development

Postby Dominus » 2017-11-10 @ 05:29

The munt midi driver is the newest build with many improvements. Ykhwong's build is ancient by now and DOSBox-x might have still used that code instead of the DOSBox patch provided by Munt
User avatar
Dominus
DOSBox Moderator
 
Posts: 7333
Joined: 2002-10-03 @ 09:54
Location: Vienna

Re: Munt Reloaded - Development

Postby gdjacobs » 2017-11-10 @ 15:29

Myloch wrote:I would have preferred to avoid installing 2 other programs or drivers that stay in memory (I already use virtualmidisynth) but I tried installing munt and a midimapper and mt32 emulation works very well with latest dosbox-x builds (default midi output). And it's a bit more accurate than how emulation used to be in the last ykhwong build and other working older dosbox versions with mt32 internal support. I wonder how the impact is (performance-wise).


The last time I tested on my netbook, Munt loaded the Atom N270 to about 70%, so the CPU usage is significant. However, it really shouldn't matter for any multi core systems running DOSBox, and you can also run it off board on another computer when using older single core machines for DOSBox or native gaming.
User avatar
gdjacobs
l33t
 
Posts: 4266
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: Munt Reloaded - Development

Postby HunterZ » 2017-11-10 @ 16:24

For performance I was comparing embedded Munt to driver Munt. The performance of the MT-32/CM-32 emulation core shouldn't be appreciably different, and may even be effectively better with the driver version because it could be more likely to run on a separate CPU core.
User avatar
HunterZ
l33t++
 
Posts: 6055
Joined: 2003-1-31 @ 19:04
Location: Seattle

PreviousNext

Return to MT-32 Development

Who is online

Users browsing this forum: No registered users and 1 guest