Great Hierophant wrote:

Would anything be gained by using the Reverb ROM at this point? The emulator uses the other ROMs inside these machines already.

After I've digged the reverb captures and drafted the algo, I believe it's useless for us and intended to use with the hardware only.

sergm, great to hear that new reverb is implemented. 😀

Not sure what kind of issues you'd like to have reported at this stage, but there is a missing sound in Space Quest 3. I think it may be an old munt issue, not necessarily related to recent development.

When Roger Wilco falls off of something there is a slide-whistle sound that is played, but with the emulation there is complete silence. The display on my MT-32 shows "Memory | Fall " when the sound is used, so apparently a custom patch. The patches are uploaded when the game starts, and the emulator console messages do list the "Fall MS" patch with no indication of an error.

Are you positive that's not one of the extra sounds in the CM-32 (or whatever it's called)?

ripsaw8080 wrote:

The display on my MT-32 shows "Memory | Fall " when the sound is used, so apparently a custom patch.

Wikipedia's list of MT-32 compatible games indicates that Space Quest 3 does not use the sound effects of CM models, but it does "exploit bugs" in older generations. Maybe this is a case of a bug exploit that's not supported in the emulation; but even if it is, I think it would be useful to identify it as such so that it could be supported at some point.

Just checked the new build. The "long note becoming squeaky whine" is now gone, as expected.

The new reverb is definitely an improvement, although Police Quest II still sounds too spacy. I don't have both module types working at the moment, but I believe that rev 0 MT-32's reverb definitely sounds thinner than CM-32L's; if I had to describe the difference, I would say that CM-32L's reverb filters high frequencies less.

Are you positive that's not one of the extra sounds in the CM-32 (or whatever it's called)?

Sierra never used the extra sounds (with once exception: Leisure Suit Larry 5, and that was composed by an external composer).

I'm almost sure, though I will check later, that the falling sound is heard on later generation modules such as the CM-32L as well. (The only bug exploit that I'm aware of in Space Quest III affects the pitch of the "TakeOff MS" sound.)
In the current emulation, one can year a very faint sound and some crackling when the falling sound is supposed to be heard.

Maybe it is a volume issue with certain kinds of sounds. The volume of the motor sound at the top of World O' Wonders on Phleebut is very low relative to others. I can hear the motor sound if I turn up overall volume such that other sounds would be uncomfortably loud, but with the falling sound there is nothing until the "squish" at the end.

sergm wrote:

But I've set volume 4 times greater 😉 Now it exactly corresponds that of the LA32 for a single partial playing.

https://github.com/munt/munt/commit/8007cb52e … a57f7b9e707fe91
Yes, but after some further commits, low volume issue is still there. Does making the volume higher create crackles or noises?

Yes, that commit made the volume right equal (almost) to the CM-32L captures. But after that we change the mixer to use floats and the volume is about exactly right again, including wet reverb output. I've tuned the reverb Level and Time parameters in accordance.

And along with the better perceived reverb there is no overdriven sound in Prince 2 😀

In the context of DOSBox this is not an issue at all. Just make greater mt32 volume in the mixer, say
mixer mt32 200
make it twice louder... Hope you know this very well 😉

Although with doubled volume overdriven sound can be heard in Prince 2...

Varka wrote:

Are you positive that's not one of the extra sounds in the CM-32 (or whatever it's called)?

The mt32emu lib can easily use CM-32L's ROMs and produce these sounds. For example, those FX in Elite plus ...

I'm intended to add reverb settings into the DOSBox patch. Would it be interesting?

sergm wrote:

I'm intended to add reverb settings into the DOSBox patch. Would it be interesting?

Sure. Are you going to add mt32reverb like mt32rate does, or to load values from midiconfig=?

@ Ykhwong:

I haven't found MT32MULTICORE #define set anywhere in DC sources. Do you compile DOSBox with MT32MULTICORE defined in config / Makefile / command line?

sergm wrote:

@ Ykhwong:

I haven't found MT32MULTICORE #define set anywhere in DC sources. Do you compile DOSBox with MT32MULTICORE defined in config / Makefile / command line?

I encountered a performance issue when enabling MT32MULTICORE with older branch of MUNT so I removed the define. However, I don't find the issue any more with the latest MUNT.

I will add "#define MT32MULTICORE 1" to midi_mt32.h in the upcoming release of mine.

ykhwong wrote:

sergm wrote:

I'm intended to add reverb settings into the DOSBox patch. Would it be interesting?

Sure. Are you going to add mt32reverb like mt32rate does, or to load values from midiconfig=?

I'm going to add mt32reverb.mode, mt32reverb.time and mt32reverb.level
for convenience

ykhwong wrote:

sergm wrote:

@ Ykhwong:

I haven't found MT32MULTICORE #define set anywhere in DC sources. Do you compile DOSBox with MT32MULTICORE defined in config / Makefile / command line?

I encountered a performance issue when enabling MT32MULTICORE with older branch of MUNT so I removed the define. However, I don't find the issue any more with the latest MUNT.

I will add "#define MT32MULTICORE 1" to midi_mt32.h in the upcoming release of mine.

I think there is no need at all. My DOSBox build now playing toughest tune and I see 0% DOSBox CPU load 😎

That sdl multithreading part is from gulikoza's patch. I modified it so that the threading process would not work in single core CPU. You can get rid of the portion. 😀

I really appreciate your awesome work. It's GREAT!
However Munt still sound wrong in some games, so I made an attempt to correct them.

Problem in detail:
X68000 version of Akumajo Dracula (Castlevania) uses MT-32 for its music. But with Munt, most custom patch didn't applied to the module and default patch was used instead.
After doing some investigation, I found that the problem lies in the Munt's sysex implementation, ignoring some messages completely.

MT-32 Owner's Manual indicates that there is two data transfer mode:
- One-way Transfer Procedure (RQ1 / DT1)
- Handshake-Transfer Procedure (WSD / RQD / DAT / ACK / EOD / ERR)

Akumajo Dracula makes extensive use of the latter, but Munt implements the former only.

I think it needs to be done properly, but since raw data of the Handshake Procedure seems identical to the One-way Procedure except additional consistency check messages (in most case, there's no need to check errors anyway) I made a quick hack to treat RQD/DAT identical to RQ1/DT1.
This makes Munt sound almost perfect for the game, though I still can identify slight difference of LFO in some instruments between real MT-32 and Munt.

PS. Hello VOGONS! 😀

After updating to latest git source (with modified reverb code), I'm getting crash in the hoot driver I use. I traced it to revmodel being called with uninitialized/random scaletuning value (negative one). It seems reverbmodel->reset is called before initial setting of reverb parameters.

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