VOGONS


munt and winx68k HighSpeed

Topic actions

Reply 20 of 33, by theelf

User metadata
Rank Oldbie
Rank
Oldbie
sergm wrote:

Thanks, the MIDIs look (and sound) very similar. This issue becomes even more interesting 😀

Thanks to you, i hope i can do more to found the problem. If more midi files, or test help in something, i will be happy to help

One thing is sure, that more complex is the music using custom patchs, more fail. For example Final Fight music with munt, sound much more similar to original MT-32 that the ones in Castlevania

Final Fight dont even do custom patchs i think

3 years ago, i remmeber i had a problem with munt, that dont work in my athlon without SSE2, and you helpme a lot 😀 this athlon machine still working with dosbox and scummvm

Reply 21 of 33, by gdjacobs

User metadata
Rank l33t++
Rank
l33t++

Would it be legit to dump a portion of the midi bitstream for testing, or would that be stretching forum rules?

All hail the Great Capacitor Brand Finder

Reply 22 of 33, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Not unexpectedly, the MIDIs sound identical on CM-64. theelf, could you ensure the captured MIDI plays fine on your hardware? BTW, do you occasionally aware of what control ROM version the unit has?

Reply 23 of 33, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

That's looking weird. There are 6 patches defined referring to memory timbres but there are no sysexes defining timbres. Also, commands 40h, 42h and 45h are used to transfer sysexes which is unlike most PC's implementations that usually use command 12h, but munt clearly handles it almost properly (not taking into account the warnings in the debug console regarding commands 40h and 45h, I'll commit something to work around this).

If there are really no sysexes sent defining the memory timbres, then it means the memory in MT-32 is preset unlike in the newer units, it is confidently cleared with zeros upon startup. Could it be the emu were sending something before the capture started?

Reply 24 of 33, by theelf

User metadata
Rank Oldbie
Rank
Oldbie

Sorry sergm, i was working,i just came home

could you ensure the captured MIDI plays fine on your hardware?

Im sorry, i dont understand very well, you say to play the midi i capture from MUnt in the MT-32?¿

Reply 25 of 33, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Yes, I'd like to ensure it isn't the capture missing timbres but the original MIDI really relies on the initial state of MT-32 timbre memory. So, please play that MIDI with your just turned on unit and see if it sounds right.

I also noticed such completely muted instruments tried to play in other game captures (along with invalid note, sysexes for different units, and so on), though nothing significant can be noticed by ear. So, I really wonder if this is another difference between old and new units.

Reply 26 of 33, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie

All X68000 emus I tested (from venerable Keropi to latest XM6 Type G) have a problem with Dracula and Munt, whether it's the stand-alone app or the Win driver. The ROM set used (MT-32 or CM-32) makes no difference -- some instruments sound correct and others are wrong, like the harp in the title screen, which is replaced by some sort or ringpad. Interestingly, if during the execution of the game I hot-switch from (for example) the Munt driver to the Munt app in the emu's MIDI settings, the correct instruments are suddenly played and the instrument name appears correctly on the Munt display. Very strange.

For reference, the same music resources play perfectly in Hoot with the Munt driver, so I think the problem comes somehow from those emulators.

Ryzen 2600X 4.2 GHz | Radeon RX 6650 XT 8 GB | DDR4 16 GB | Win10-64 Pro

Reply 27 of 33, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

This sounds like real units ignore any attempt to set up a patch that refers to an initialised timbre. Need to check this.
Or maybe MT-32 initialises all memory timbres to one of the standard banks (presumably A).
Still, I suspect a CM-32L-like unit should have the very same problems with x68k emu.

Reply 28 of 33, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie

I'll give it a try with my CM-500.

For info, this is a recording I did ten years ago (!) on my unit with the Hoot player.

Ryzen 2600X 4.2 GHz | Radeon RX 6650 XT 8 GB | DDR4 16 GB | Win10-64 Pro

Reply 30 of 33, by Kaminari

User metadata
Rank Oldbie
Rank
Oldbie

Just a quick note. I ran Dracula on my CM-500 and it plays correctly.

I used SendSX as a MIDI passthrough between X68 emu and my synth (via LoopMIDI). The exact same setup with the Munt driver instead of the CM-500 plays a couple of wrong instruments in the intro and title screen. I can capture the MIDI commands in SendSX, but my understanding is that they will be exactly the same whatever the synth I choose as the output in SendSX, right?

Ryzen 2600X 4.2 GHz | Radeon RX 6650 XT 8 GB | DDR4 16 GB | Win10-64 Pro

Reply 31 of 33, by sergm

User metadata
Rank Oldbie
Rank
Oldbie

Very interesting. I wonder if there is a difference when you capture a MIDI and then play on both CM-500 and munt.

EDIT: Well... I've found the game seemingly loads the timbres at the start and does not reload them in the sound test mode for some reason.

EDIT2: Most suspicious are rows "playSysexWithoutHeader: Got SYSEX_CMD_DAT but partials are active - ignoring" in the munt console. It well may ignore the timbre sysexes. Not sure why KingGuppy added this check, though.

EDIT3: MT-32 owner's manual claims that the unit sends rejection "if any part is reproducing sound". However, CM-32L manual doesn't seem to contain this statement. Anyway, it looks like real units happily accept data sets in any circumstances (and the emu doesn't even require ACK to proceed). Funny thing: both munt and the emu loosely implement handshake communication protocol. I'd better just disable that check until real bi-directional API will be available and we will be able to properly send rejections. I wonder if real old MT-32 connected via a single MIDI cable works well with that...