"Try to get a hold of" sounds as if you had no idea where to get them 😉

You're right, though I did mean something else by it 😊
And if I didn't knew where to get MUNT, how would I be able to notice the change in the said patch? =P /offtopic

Who knows? You could have used direct links before and kept your download...

marooned_on_mars wrote:

I've been noticing a quirk in the MUNT version 1.2.1 and up until now, wherever "IceRain" is played, it has an obnoxious pop preceding it. Sample:

The attachment ice rain pop.ogg is no longer available

I'll also try to get hold of an older MUNT, and test out from when exactly this behaviour started.

Heh. You'd better try to get a recording from a real unit. It seems it is rather a bug in the control ROM 😉

You seem to have guessed right that I was using a CM-32L ROM, however I also tried a MT-32 ROM as well:
CM-32L v1.02 and MT-32 v1.07. I don't have any other ROM versions to confirm.

Sergm, i have a pull request to update the dosbox patch to apply on the current dosbox svn, if you want it. If you don't, just reject it.

My dosbox ppa built package isn't actually asking for the mt32 ROMS location at the moment although i thought it was. This is because the libmt32emu library i'm building is static, and therefore, the user will never see the scripts i put in the debian postinst script (i was testing it by installing the lib package myself, which is obviously something the user will never do).
So, that was a SNAFU, and i'm planning to solve it by creating another package that will only install the script for copying the roms and maing it a dependency of mine dosbox and exult packages (or maybe of the libmt32emu, if runtime deps will 'transfer over' for static libs).

Hey Sergm, I've noticed a song that started to crackle for me in Hoot using recent versions of munt. I've converted my hoot driver to dos and tried a recent dosbox with newest munt and it crackles too. It's a FOFT title song by Barry Leitch from an unreleased pc port of the game. Attached is the dos version of the music, unpack to some dosbox folder and run code.com to play. It used to play fine in an old dosbox compile from a year+ ago but I don't have a real cm32/lapc1 to try, so I'm not really sure if it's not some local problem here.

Confirmed that mt32 emulation displays above "static issue" with 1.30 and later. However, Ykhwong's build works fine and documents a mt32 emulation update on 4/21/13 (presumably 1.20). Therefore, the issue must have been caused between 1.20 and 1.30 (a commit between 3/24 and 9/22); although there is a small possibility that this is a mingw specific problem (given MUNT is also compiled by mingw/gcc). Tested on win32 platform and using single thread option.

Additional testing: "static issue" does not occur where mt32.reverb.mode=0,1,2,3. It does occur, however, where the parameter value is "auto".

truth5678 wrote:

although there is a small possibility that this is a mingw specific problem (given MUNT is also compiled by mingw/gcc).

It's not a compiler - I used VS2008 to compile munt dll for hoot.

There is a lot of crackling on the real mt32 module (old version) in this whole song. (similar to new munt)
On the real cm32l module the crackling starts from about 1 minute 45 seconds but is mostly less noticeable than in mt32.

robertmo wrote:

There is a lot of crackling on the real mt32 module (old version) in this whole song. (similar to new munt)
On the real cm32l module the crackling starts from about 1 minute 45 seconds but is mostly less noticeable than in mt32.

Thanks for testing. I guess this might become a victim of perfect emulation then. Yeah, I'm in a minority that prefers better sounding emulator to a perfect one 😜 Maybe when I get really bored I'll try adding some overflow checks in various places in the reverb code and see if it fixes the issue.

Hey, guys!

@SCO: I'll try to look at your pull request asap. Though, the patch for DOSBox isn't the "official" code but a sort of "a way to go" or "howto". It is intended for developers as a starting point for not to invent a wheel. So, my point is to keep it as is for use with the current "official" DOSBox release and perhaps adding another patch from you to use with modern SVN thunk. But I definitely have no time to support it, and thus I'd prefer to just place a link to your version.

@Mok: Awesome. I think Barry set the master volume a bit too loud. Making it down to 70 prevents overdrives on my CM-64. Overdrives in Munt is another matter. He set reverb ROOM/7/7 at the beginning and DELAY/7/7 further that's quite loud too, and it is mixed down with the LA32's output in integer (since v1.3, yes). A real device throw at the DAC the streams from LA32 and BOSS separately and mix them in analogue. So, I'm unsure which is best and maybe reconsider. But anyway, specially for guys like you, who prefer good sounding vs. speed or emulation accuracy, we have MT32EMU_USE_FLOAT_SAMPLES compile option which now (again, since v1.3) produces output in float - never ever overdrives, less rounding noise, accurate sine/exp functions instead of LUTs. I hope you appreciate it. 😀

@truth5678: By setting the reverb mode to 0/1/2/3, you just tell munt to ignore reverb-related sysexes. So the time/level remain at the default values 5/3 in accordance, thus reducing the overdrive probability.

Though, it may well be just a bug in the new reverb code. 😒 Even turning off the LA32 output, the reverb tail is still sounding corrupted.

It may appear that BOSS does clipping when adding samples but in the emulation an integer overflow may happen. I'll add the check to be sure if this is the case.

sergm wrote:

ok: Awesome. I think Barry set the master volume a bit too loud. Making it down to 70 prevents overdrives on my CM-64. Overdrives in Munt is another matter. He set reverb ROOM/7/7 at the beginning and DELAY/7/7 further that's quite loud too, and it is mixed down with the LA32's output in integer (since v1.3, yes). A real device throw at the DAC the streams from LA32 and BOSS separately and mix them in analogue. So, I'm unsure which is best and maybe reconsider. But anyway, specially for guys like you, who prefer good sounding vs. speed or emulation accuracy, we have MT32EMU_USE_FLOAT_SAMPLES compile option which now (again, since v1.3) produces output in float - never ever overdrives, less rounding noise, accurate sine/exp functions instead of LUTs. I hope you appreciate it. 😀

It's possible that the original game was decreasing the master volume before playing, but since it wasn't released (probably not finished either) I simply added a generic MT32 driver by Leslie Long that was used in most early Barry's works for Imagitec/Gremlin/etc. Can't remember if it allows to change master volume or not.

And yeah, I appreciate your work a lot. It's hard to believe how much this project advanced in the last few years 😀

It may appear that BOSS does clipping when adding samples but in the emulation an integer overflow may happen. I'll add the check to be sure if this is the case.

Thanks. Emulating bugs needed for proper playback (like early mt-32 revisions) is important, but something like lack on overflows in reverb shouldn't really affect anything negatively.

When loading sysexes, the master volume is set to 75 to avoid overdrives. Unfortunately, this isn't enough. Now, I realize this is because of unreleased state.

Anyway, something needs to be done with reverb. While it is fine in the float mode, it sucks in the default integer mode. So, thanks again for reporting it. 😀

Mok
Side note: the tracker file FOFT.RLD you attached actually contains the instrument names, but MT32.DRV doesn't send them to MPU for some reason. Isn't it intended for CM-32L / LAPC in fact?

The integer overflow occurs when the reverb processor adds three comb filter exits. The resulting sample appears significantly out of range and the current reverb model is likely very accurate in the rest. This makes me think BOSS chip has an accumulator with precision of 17 (or more) bits and clamps the result. Or just carry may be used for this.

sergm wrote:

Mok
Side note: the tracker file FOFT.RLD you attached actually contains the instrument names, but MT32.DRV doesn't send them to MPU for some reason. Isn't it intended for CM-32L / LAPC in fact?

Barry Leitch used a LAPC-I when he was doing LA-synth music, so all his music probably sounds best on that 😀

Then MT32.DRV is a weird name for the driver. 😀