VOGONS


DosBox v0.70 MIDI handling for the rev00 MT-32 Roland synth

Topic actions

Reply 60 of 79, by JCZorkmid

User metadata
Rank Newbie
Rank
Newbie

I have an MT-32 rev00 on Mac OS X connected via an M-Audio USB interface and virtually everything was causing this issue for me. I posted a patch to the tracker a few days ago that introduces a delay based on the size of the sysex data and the standard MIDI baud rate of 31250 (props to ScummVM for that) plus an optional constant delay (for differences in hardware, etc).

Rather than introduce the delay when the sysex message is first sent, the time at which it is "safe" to send the next MIDI command is stored, and the delay is before the next MIDI command (sysex or not) is processed. This allows for games that do other things while sending the sysex data or may already be working around this issue. It also minimizes visible slowdown.

JasonPenney.NET

Reply 61 of 79, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Sometimes I have the feeling that the better USB-Midi devices work worse with the MT32. We've had a report for the buffer problem with Exult which neither of us devs with a real MT32 + cheap USB-Midi device can reproduce either on Windows or OS X.
But this doesn't mean you are not right to pursue this 😀

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 62 of 79, by JCZorkmid

User metadata
Rank Newbie
Rank
Newbie

I thought I recognized your name from somewhere. I had submitted an (unrelated) Exult patch a few weeks ago. 😀

I'm pretty sure my USB-MIDI adapter is the cheapest one that doesn't just ignore sysex messages (unlike the fancy one I have which doesn't seem to work with the MT-32 at all). Is there an Exult ticket? I can try and reproduce it when I have some free cycles.

JasonPenney.NET

Reply 63 of 79, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Ah, you've been the clang guy 😀
Yes, a bug report for https://sourceforge.net/tracker/?func=detail& … 0&group_id=2335 and in there I just linked your patch for Dosbox a couple of minutes ago and in the original post a link to the actual bug report in our forum.

Before you get disappointed, as in the forum post, Exult does not playback the intro correctly currently on a real MT32 with a cheapo USB adapter (as my recording on OS X is similar to the one the forum poster made on Windows 7, I presume it's a problem with Exult and not just either OS X or cheap adapter). If you feel like taking this one, be it just by confirming the buffer problem or a nice little patch, you are welcome to and I can assure you we will take a serious lok 😀

Reply 64 of 79, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Just a quick update; I have made yet another version of my patch which uses some of JCZorkmid's ideas; for details look at the aforementioned SourceForge location. This one removes support for the delayreadystate solution, as it didn't provide any benefits. More importantly, it is based on a new delay calculation and should now compile on Linux and Mac platforms as well. I've actually tested it successfully on a MacBook Air using my Cakewalk UM-1G; no buffer overflows!

Regards,
Ronald

Reply 66 of 79, by TeaRex

User metadata
Rank Member
Rank
Member

There's a problem with the SVN addition. Wbat exactly is the function remove() in line 203 of midi.cpp supposed to be and where is it defined?

VC++ Express 2010 gives an error along the lines of remove having only one parameter called "FileName", not three, so the function it is thinking of seems to be a function intended to delete files, not remove a character from strings as intended. I tried std::string::remove on a whim, but that doesn't exist. Unfortunately that's about the limit of my C++ abilities. Thanks for your consideration!

tearex

Reply 68 of 79, by TeaRex

User metadata
Rank Member
Rank
Member

Fix confirmed.

tearex

Reply 70 of 79, by HunterZ

User metadata
Rank l33t++
Rank
l33t++

Exciting to hear that this is now in the official DOSBox source! Thanks to those who worked on it.

Reply 71 of 79, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for adding it into the main tree, Qbix! And thank you Jason, for your input and suggestions! Thanks to all beta-testers!

Reply 72 of 79, by JCZorkmid

User metadata
Rank Newbie
Rank
Newbie

Thanks very much for getting this into the main tree! And thanks to Ronald for all his help.

JasonPenney.NET

Reply 73 of 79, by Vigil

User metadata
Rank Newbie
Rank
Newbie

Bit late to the party on this, but... Colonel's Bequest by Sierra still has problems on my rev01 (whoops, not rev00) MT-32 even with the SVN patch.

The game makes extensive use of custom instruments and without sufficient sysex delays, my MT-32 misses several instrument customisations: instead falling back on the default instruments (or possibly getting 'half-customised' ones, I can't tell) with often hideous consequences.

The sysex delay in the patch helps - the MT-32 misses fewer instruments when it's enabled - but I had to impose a minimum sysex delay of 40ms to ensure that all instruments sounded as intended. (By contrast, the maximum delay calculated by the sysex patch was about 35ms.)

I'm away from my MT-32 for a week so I can't narrow down yet which sysex messages are getting dropped or cut off, but I'll post more results once I can test it again.

EDIT: Ahh wait, actually I have a rev01 MT-32 (SN 865037), not rev00. And this is a Macbook Air with a no-name USB-to-MIDI adapter cable.

EDIT 2: This was tested by integrating the SVN patch into Boxer 1.0.1 (whose MIDI handling is the same as the release version of DOSBox 0.74.) Without the delay, Colonel's Bequest still had missing/broken instruments at 2000 cycles, with more of them at 3000 and above. With a delay of 40ms, music sounded correct at any CPU speed.

Boxer 1.0.2 includes a version of the patch with a quick hack to set the minimum delay to 40ms when delaysysex is enabled. (This is obviously not a proper solution, but didn't negatively affect any of the games I tried - apart from considerably slowing load times.)

Last edited by Vigil on 2011-04-21, 14:11. Edited 1 time in total.

Reply 74 of 79, by rcblanke

User metadata
Rank Oldbie
Rank
Oldbie

Thanks Vigil, I'll see if I can reproduce it at home. I've noticed that NFL Football also seems to require an additional 2 ms. delay, maybe the calculated delay is a tiny bit too short.

Reply 75 of 79, by Vigil

User metadata
Rank Newbie
Rank
Newbie

Out of curiosity, how did you arrive at the constants used in the current patch's delay calculation ((payload * 1.25) + 2)? I didn't catch an explanation of those in the rest of the thread.

Reply 77 of 79, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

If you are having problems with thr rev01, then you really should make sure that the USB adapter is not the weak link. There have been reports of some that don't work correctly. I don't have that game but maybe we can work something out. I'm on a mac, too with a rev 00 mt32.

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper

Reply 78 of 79, by JCZorkmid

User metadata
Rank Newbie
Rank
Newbie

Vigil, reading your post it sounds like you aren't using the actual code that was accepted into DOSBox, but one of rcblanke's older patches... is this correct? Can you test the actual code that's in the latest DOSBox tree (no patches) and see what you get?

I will note that most of the other programs that work around this issue do so using:

((midi.sysex.used+2)*1000/3125) + 40

Which is enforcing the defined MIDI baud rate (plus 40ms, which is due to a specific MT-32 bug), rather than the code that eventually made it into DOSBox:

(Bitu)(((float)(midi.sysex.used) * 1.25f) * 1000.0f / 3125.0f) + 2;

But rcblanke had better luck with the latter.

Also, any time you get any error on your MT-32 I recommend you power cycle it before doing any more testing, because it will continue to get errors even when it should not otherwise.

JasonPenney.NET

Reply 79 of 79, by Vigil

User metadata
Rank Newbie
Rank
Newbie

Dominus: the adapter certainly could be introducing problems of its own, e.g. it could be dropping larger MIDI messages that are coming down the pipe too quickly. I would need either another connector or another MIDI device to rule it out altogether, but you could try to replicate the Colonel's Bequest instrument problems (or buffer overflows) on your rev00. Are the rev01's not known to have any lingering MIDI-processing limitations of their own?

JCZorkmid: I ported changesets 3687 and 3688 from DOSBox SVN: http://dosbox.svn.sourceforge.net/viewvc/dosb … 688&view=markup. I oversimplified the constants in my post, the actual code being used is (Bitu)(((float)(midi.sysex.used) * 1.25f) * 1000.0f / 3125.0f) + 2 as it is in the accepted patch.

(I also make sure to always power-cycle the MT-32 between launches of a game when testing.)