NewRisingSun wrote:

I have spent some time now checking several hours of MT-32 music, often preparing to post a bug report, only then to find that the error is either with the games' MIDI player itself or DosBox' emulation of it, and not MT32Emu. Brilliant!

Are there still issues with DOSBox midi interface emulation with Roland devices? This is the first time I have read of them in a long time.

The interesting thing is that these are pretty much the worst "bug reports" in existence since they
claim something doesn't work (most often it's plain user dumbness in getting that to work,
but I won't put up that stance here) and since there is not a single useful detail in that report
things stay as they are (random code changes are no usable progression technique) and the
same person will continue that claim from time to time.

I finally found a bug in MUNT itself. Yay! 😉

It's the title music in Dynamix' "Heart of China". The harp notes (in attached CHINA.MID starting at measure 64:1:000) are for the most part missing. I have extracted and attached the offending passage in TEST.MID for easier access.

I think the reason is that these notes are of zero duration, that is, they get turned off immediately after they are turned on. This should not matter with a "durationless" instrument like a harp, and a real CM-32L plays them correctly. Unlike MUNT, where the zero duration notes are silent and only the duration=6 notes play. I have reproduced it by playing the game in DosBox, so it's not just a problem with SMF2MID.

NewRisingSun wrote:

I have spent some time now checking several hours of MT-32 music, often preparing to post a bug report, only then to find that the error is either with the games' MIDI player itself or DosBox' emulation of it, and not MT32Emu. Brilliant!

NewRisingSun could you please tell us what games had errors with dosbox?

Honestly all mt32 games I tested so far work like a charm with ykhwong build from 3 september 2011 and the differences with real mt32 sound are now subtle. I cannot understand where are all the problems NewRisingSun encounters...

Are there still issues with DOSBox midi interface emulation with Roland devices? This is the first time I have read of them in a long time.

It took me long to respond because I wanted to find the root cause. I have not been successful. 🙁

There's a strange high garbage note when starting up "4D Sports Driving" (aka "Stunts") in MT-32 mode that's not there when I play the game on a real DOS machine with a CM-32L. It IS there however under DosBox with MUNT, and it's also there if I log the MIDI output in DosBox, then play back the resulting MIDI file on the real CM-32L. Hence my assumption that the error lies with DosBox, not MUNT.

The garbage note is on channel 3 (or 2, if you count from zero) note number 0x7B. It looks like controller 123 for some reason gets interpreted as a note number.

I cannot understand where are all the problems NewRisingSun encounters...

Hey, I've only mentioned one single issue...

the the root cause 😉
http://dosbox.svn.sourceforge.net/viewvc/dosb … n&revision=3238

Care to explain, robertmo? Was it working correctly before this change?

yes 😀

Hi, guys!

That's all fine that the Munt engine sounds so cool now, but we still have un(der)explored that Thunder bug in CB. It'd be great if someone could help.

About the harp zero duration notes in "Heart of China", I believe this is a sort of improper MIDI programming. Really, any device with true MIDI interface cannot record zero-duration notes since the MIDI transfer rate is 31250 bps, i.e. any subsequent MIDI message must be recorded by a sequencer about 1 ms later. [EDIT] Though this assumes PPQN 480 or 500 as DOSBox provides. Lesser PPQN values, of course, allows such "durationless" messages... [/EDIT] And this is exactly true in the case of playing those zero-duration notes on a real h/w module: NoteOn and NoteOff messages cannot be received closer then at ~1 ms duration. Maybe we should emulate this stuff in the synth...

What I'm interested more is how about those insufficient partials cases. Can anyone provide information on how that sounds on a real module compared to the Munt output, preferably smf2wav. I think Munt's partial abortion algorithm is the cause of the Thunder bug...

I've noticed a couple of Sierra soundtracks where partials are dropped off differently in Munt and on an MT-32. It was sometimes very noticeable in some Gabriel Knight tracks (if I recall correctly) where the lead instrument would be prematurely muted in Munt, while it's still audible on the real synth.

I'll try to go through those soundtracks again and pick up specific examples.

I can confirm there is a high pitched note on stunts (4d sports driving) intro song that is really strange.

@sergm: what's that thunder bug in colonel bequest? it seems fine to me.

Myloch:
Actually, there're two:
1st reported by Kaminari Munt Reloaded - Development
and 2nd reported by Androidi http://sourceforge.net/tracker/index.php?func … 616&atid=697157 (though maybe this one isn't a Munt bug as well)

sergm wrote:

Myloch:
1st reported by Kaminari Munt Reloaded - Development

The "hanging" issue seems resolved, but the larger problem is that Colonel's Bequest (and other Sierra games besides) features timbres that make use of limitations in the original LA32 chip design. Since these "bugs" were resolved in the later hardware, which MUNT seems to be based off of, these timbres will only sound correct if these so-called bugs can be properly identified and implemented as MUNT options.

Here is an example of the "Lightning" timbre, as played-back on both 00 and 01 (new-type) MT-32s (the latter bearing the same LA32 chip as found in the CM/LAPC units):

http://www.symphoniae.com/synth/Roland/MT32/W … ightning_00.WAV
http://www.symphoniae.com/synth/Roland/MT32/W … ightning_01.WAV

You'll find that MUNT matches the output of the "01" unit.

and 2nd reported by Androidi http://sourceforge.net/tracker/index.php?func … 616&atid=697157 (though maybe this one isn't a Munt bug as well)

We're dealing with the same issue here, with the "SwmpBackgr" timbre. (MUNT, again, matches the latter output):

http://www.symphoniae.com/synth/Roland/MT32/W … mpBackgr_00.WAV
http://www.symphoniae.com/synth/Roland/MT32/W … mpBackgr_01.WAV

Thanks Cloudschatze, that's really useful information. I was a bit mystified when everything I tried to reproduce the reported lightning bug gave (more or less) identical results on my CM-32L and Munt.

Are you sure that the differences are due to different LA32 revisions rather than firmware bugs?

I'm not sure of anything, really - it's pure conjecture. 😀

The problem with this thought is that both the "old" and "new-type" 01 MT-32s appear to share the exact same LA32 chip (at least, according their Roland part numbers). Since the output of the "old-type" 01 MT-32 matches that of an 00 unit, and not the newer units, we'd have to assume that Roland produced two different chips with the same part number, else the LA32 isn't the culprit at all.

If the problem is firmware-related, shouldn't MUNT's output match that of an 00 MT-32 when both the 1.07, 10-Oct-87 ROM is used, and the DAC input mode is set to "GENERATION1"? (It doesn't, per my testing.)

Cool, thanks, Cloudschatze! We really worked hard on 01 chip of KG's CM-32L only.

But, I'm still a little confused about that bug #1... Kaminari named his sample as LauraBow_CM64 for some reason, so I assume he used exactly CM-64 (equipped with the new chip, right?). One could clearly hear that Lightning patch sounds exactly as Lightning_01.WAV.

However, I suspect, the cause of that hard distortion is that Thunder patch shuts down due to insufficient of partials on the real hardware. In contrast, Munt leaves it playing. I presume, the oldest partials must go off when an insufficient is encountered, right? But Munt doesn't perform it exactly the way the real hardware does.

[EDT]
@Kaminari:
In order to confirm that, could you, please, redo LauraBow_CM64 but for channel 5 (Thunder MS) playing solo and compare it with Munt?
[/EDT]

when i mute in cakewalk all tracks but 5 i get distortions simmilar to munt with my cm32l and mt32oldtypepcb1
so you found the problem 😀

btw if you edit a post you may be sure not many people will notice it as it doesn't highlight for people who already read the unedited post. so it is better to delete the post and post again, or post another post.
Although deleting a post and posting again may make a mess if someone replies to the deleted post 😉 so it is better to post another post

Cool 😀
Nevermind, robertmo, I can wait 😀 and Munt can wait, and time is not important 😀))

Looking even more closely to that specific MIDI pattern in CBMT.MID started at 8:15.04, I became to a conclusion that the partials of Thunder MS more likely shut down either by the sequence:

STATUS DATA1 DATA2 CHAN NOTE EVENT

178 64 0 3 --- CC: Pedal (Sustain)
178 1 0 3 --- CC: Modulation
226 0 64 3 --- Pitch Bend
179 64 0 4 --- CC: Pedal (Sustain)
179 1 0 4 --- CC: Modulation
227 0 64 4 --- Pitch Bend
180 64 0 5 --- CC: Pedal (Sustain)
180 1 0 5 --- CC: Modulation
228 0 64 5 --- Pitch Bend

at 8:15.15 or by the subsequent SysEx:

WRITE-SYSTEM:
Master Tune: 441.990082
Reverb: mode=0, time=5, level=3
Partial reserve: 1=00 2=00 3=00 4=00 5=00 6=00 7=00 8=00 Rhythm=00
(Partial Reserve Table with less than 32 partials reserved!)
Part assign: 1=01 2=02 3=03 4=04 5=05 6=06 7=07 8=08 Rhythm=09
Master volume: 100

which BTW sets partial reservation table to all 0. At least what I’ve found helpful, there is a Program Change in channel 3 right after the control sequence and it REALLY aborts Thunder MS partials (but for channel 3 only). When I changed those Pitch Bend messages to Program Change, I got it very nicely sounding…

So, robertmo, may I ask you to play some more on this (or maybe anyone else can)?