@ wonst719:

Thanks for your kind words and participation! I wish every user was able not only to report a bug but to send a patch for fixing it 😀

BTW, if you really want to work on the project, don't hesitate to consider registering on GitHub 😀

worst719, thank you very much for pointing this out. I have some uncommitted sysex read code that also includes support for the handshaking sysex method. I wasn't aware that any games used this method, so I wasn't planning to commit it until we had complete sysex read support. It's very good to know, and I'll commit the minimal implementation (as in your patch) as soon as possible. Presumably the game doesn't actually care about getting any responses from the MT-32 for true handshaking.

sergm wrote:

Strangely... Commit f4f2336790157d0ffaab was intended to get rid of this 😒

Weird. It seems the download on the git page isn't updated immediately after each commit as I downloaded the source about 15 hours ago (after your last commits) and it does not include last changes. Sorry for the noise. It starts now but I hear a lot of noise. Doesn't matter really, I'll wait till you get it ready 😀 Excellent work overall, thanks for joining the project 😀

Edit: after messing a bit with compiler options the weird static noise is gone and I have problems to recreate it now. Either another uninitialized variable somewhere or a problem on my end. In any case it's all good now.

Mok wrote:

Weird. It seems the download on the git page isn't updated immediately after each commit as I downloaded the source about 15 hours ago (after your last commits) and it does not include last changes. Sorry for the noise.

Out of curiosity, How did you get the source? Do you mean downloading tar / zip? I'm using git and have never seen it failed... It was several minutes delay in updating once, but what I see via http is what I get via git usually 😒

Mok wrote:

In any case it's all good now.

I hope so 😀 I think it's probably the best we can get out of freeverb's combs / allpasses tuning... Thus, if some critical problem is encountered, we'd need to change the algorithm completely...

@sergm
Thank you! But my knowledge of the MT-32 is very limited, I don't think there are many things that I can do.

@KingGuppy
Glad to hear that the work has already begun! I'm looking forward to seeing the work completed. 😀

It's just a matter of how you're interested in the development 😀

DOSBox patch now incorporates three new configuration options:
mt32reverb.mode, mt32reverb.time, mt32reverb.level

If mt32reverb.mode set to "auto", there is no changes in behavior.

One more note: the current implementation doesn't freezes reverb settings completely. When mode 3 is set and the game sets another mode itself, reverb mode will be changed in accordance. And vice versa. However, when you set mode, e.g. 2, and the game sets mode, e.g. 0, your settings will be preferred 😀 I think after we've cleaned up the reverb code, this problem will be gone, eventually...

Option mt32rate was finally deleted since you cannot get with it anything except the loss of quality and emulation accuracy 😀

So, to clarify, dosbox patch is not a standalone patch anymore but instead requires munt reloaded as a library?

Dominus wrote:

So, to clarify, dosbox patch is not a standalone patch anymore but instead requires munt reloaded as a library?

What's that "munt reloaded"? 😀

Yes, my patch uses statically linked mt32emu library as it is intended to be used. So, you need to compile it separately and install.

I downloaded the patched build you (sergm) posted on github a few minutes ago and compared that to the other build i was running. The difference is unbelievable, and the music sounds great. Cpu usage was 5-7% while the intro played.

Wish i could do more then just say great work 😀

What's that "munt reloaded"?

Check the thread you're posting in.

wd wrote:

What's that "munt reloaded"?

Check the thread you're posting in.

I can't merge it in any other thread 😀

Although, the is no general Munt Development thread and too few specific threads (almost useless) as well... So, I post here 😀

From what I understand:
It's no longer 'reloaded' as it's now merged back into the main Munt repository
It's a library that is statically linked to
The Windows driver may/may not be provided - I know nothing about RTP-MIDI (seems to be for sending MIDI across a network and compatible with OS-X...still none the wiser on how this is of use to a Windows system!) and I can't work that one out from the postings 😀

Just a [small] suggestion... why not add a FAQ/feature plan on the Munt 'web site' or possibly start a new thread here with just that - what it is, how it works on Windows & other platforms, what other components are required, what features are being worked on/planned in.

From what's been posted over the last couple of weeks there seems to be some fantastic progress. Great work on that!

Very good point! I think I'd start such a thread aimed to the release upcoming soon...

You can also get more information on (and track the status of) the future direction in an issue that was abused for this purpose:
https://sourceforge.net/tracker/?func=detail& … 616&atid=697160

I've just added your recent implementation for reverb settings to my release. Thanks, sergm. 😀

Holy smokes! Listening to the latest build and it sounds really, really good! Awesome work!

Without KingGuppy's help and his "black box" there wouldn't be such a progress! But now I suppose we're getting really close 😀

ykhwong wrote:

I've just added your recent implementation for reverb settings to my release. Thanks, sergm. 😀

You're slightly too fast, Ykhwong 😉

I've added two more options in the patch:
- mt32log to control its noise. This is the proper way to filter LCD messages to show and you don't have to comment out every printDebug by hand 😀

- mt32DAC which make possible accurate emulation of overdrive cracklings I suppose some games use it for FXs.

sergm wrote:

You're slightly too fast, Ykhwong ;) […]
Show full quote

You're slightly too fast, Ykhwong 😉

I've added two more options in the patch:
- mt32log to control its noise. This is the proper way to filter LCD messages to show and you don't have to comment out every printDebug by hand 😀

- mt32DAC which make possible accurate emulation of overdrive cracklings I suppose some games use it for FXs.

Your code:

1+      if(!strcmp(section->Get_string("mt32log"),"on")) {
2+				noise = true;
3+			} else {
4+				noise = false;
5+			}

What about adding #include "debug.h" and the following code?

1+void printDebug(void *userData, const char *fmt, va_list list) {
2+#if C_DEBUG
3+	printf("MT32: ");
4+	vprintf(fmt, list);
5+	printf("\n");
6+#endif
7+}

Alternatively, you may change "tmpProp.printDebug = printDebug;".

With this change, debugger-enabled builds of DOSBox will output log messages.