Are you using the same version as me?
Have you actually tried sysex line that is longer than 128 bytes (from F0 to F7)? Maybe try dune 2 sysex or the long one we were talking about above.
The speed doesn't matter for munt, though for real mt-32 i had to use 0,54kB/s

It is possible that there is a bug in SendSX cause for me
"Split long sys ex messages" from drop down menu is the same as "Wrap long sys ex messages upon loading" (when you change one the other changes too) and what it does is wrapping messages but also splitting them to 32 bytes (you can change the value in windows registry but if you go higher than 128 there is still some lock that keeps splitting to 128 bytes and you cannot go higher even though the wrapping goes higher)

It looks they were doing something with that sysex messages as there also is a SplitLongMessages2 registry entry which means there should also be SplitLongMessages1 which is not there.

I already posted on Bome's forum and waiting for reply.

Hi Robert,

Yes, I'm using build 182. Long sysex lines like the ones from Dune 2 work fine (with standalone Munt app + LoopMIDI). I didn't try with the Windows driver though.

can you try that without loopmidi?
just choose mtemulation as output in sendsx

I had this problem with midi yoke too.

I installed midiloop and indeed there is no such a problem with midiloop and speed set to something else than infinite in sendsx.

The strange thing though is that munt no longer reports problems with xeen's too long sysex now. And it doesn't matter whether i play it through midiyoke or midiloop or straight to mtemu. Can you explain that sergm?

Of course. The length of sysex messages is limited in the built-in MIDI player only. There is no limit in the emulation core or the win32 driver.

once when i started dosbox 0.74 i got buffer underrun (enlarge buffer) in the console
also once when i started playing some cm-32l song i got a message in the console that it is not a mt-32 header.
couldn't reproduce both.
don't know if it is important but just in case and also just being curious
i wonder what happened? does that mean something is not fully reliable?

Hmm, buffer underrun usually means busy CPU / low audio latency in the "Audio Output / Properties". Choosing PortAudio / DSound output helps especially along with increasing the priority of the mt32emu-qt process up to real-time.

"not a mt-32 header" not necessary means a error happened. It can mean normal behaviour of a MIDI player / game that blindly sends sysexes intended for different manufacturers/models. E.g. gsplay always does if you don't suppress device resetting. So, not sure about this one.

Someone mentioned earlier in the thread that the distorted guitars don't sound right in MUNT. I happen to have noticed the same problem in TIM2, a game that I've recently recorded, and I've attached the problematic tracks. It was recorded with MUNT 1.1.1, but 1.2.0 has the same problem unfortunately.
Also, unfortunately I don't have a hold of how those tracks sound with real hardware, but I know it definitely doesn't sound right 🤣.
Just thought about letting you guys know ^^

marooned_on_mars
I'm not involved in MUNT development, but I was going to do a quick run of those levels using my MT-32(old) and record for comparison... (Hey, I own both an MT-32, and a copy of The Incredible Machine 2, why not help out 😀 )
Digging around in TIM2's setup, I did not see anything MT-32 related... amd a quick web search found this: http://queststudios.com/Joomla/index.php?opti … ine-2&Itemid=96

The MT-32 was not used by TIM 2, although it can be made compatable by loading a special patch ahead of time.... So the audio SHOULD sound wrong with MUNT in this case, as far as I can tell.

vel wrote:

marooned_on_mars
I'm not involved in MUNT development, but I was going to do a quick run of those levels using my MT-32(old) and record for comparison... (Hey, I own both an MT-32, and a copy of The Incredible Machine 2, why not help out 😀 )
Digging around in TIM2's setup, I did not see anything MT-32 related... amd a quick web search found this: http://queststudios.com/Joomla/index.php?opti … ine-2&Itemid=96

That's really nice of you to help out =)

vel wrote:

The MT-32 was not used by TIM 2, although it can be made compatable by loading a special patch ahead of time.... So the audio SHOULD sound wrong with MUNT in this case, as far as I can tell.

That's a bit odd, the installation screen makes MT-32 MT-100 CM-32L and CM-64 available, and it doesn't include Sound Canvas, so it's not that let's say it was composed for it but they slapped together some MT-32 support. It seems like TIM2 is in a similar case but instead with GM music "ported" to MT-32 from what you said.
But did the tracks sound the same on the original hardware too, or is it only a MUNT issue?

Interesting... my version of TIM2 does NOT offer an MT-32 option in the installer... But then, it was given to me by a friend while I was visiting India, who also did a lot a international traveling, so who knows where it originated.
I'll grab a gog.com copy and see if that has an Mt-32 option, and report back (with recordings) some time next week.

Ah, perhaps you have the dos cd version or an european re-issue. Not exactly sure since I don't know how TIM2 was released ^^;
Sure then, will wait for you to report =)

vel check your messages

@marooned_on_mars
May I remind that wave captures are virtually useless for me to analyze munt bugs? 😉

i enclose a quick mt32old recording

and the roland virtual sound canvas recording

@sergm : I know, but I posted them anyway since I didn't know how to explain the issue! =)

@robertmo : Thanks for the recordings, at least that sheds some light onto this. So in this case it wasn't a MUNT quirk, it was actually "supposed" to be played as such. Maybe by a long stretch the composer actually wanted it to sound that way.

I'll have to check NRS and tikalat's fixed installer to see if there's any difference and edit this post to report ^^

Sorry again for veering this topic out of it's purpose ^^;

your recording files are done from munt so why are they called IBM-PC CM-64?

That's the way I tag the files in my project. It is CM-64 because the game uses some capabilities from the unit that aren't present in the MT-32. (at least from what I know)

so should be like
Huey Dewey[!] (IBM-PC CM-64 MID) on Munt.ogg
your currant way is extremely confusing as it suggest it was recorded on CM-64. That name would be fine for a .mid but is not for a recording.