MIDI: Add pauses between SysEx messages at beginning of game

Logged In: YES
user_id=1103943

How are you connecting your MT-32 to your computer? Serial
port? MIDI/joystick port? Which OS are you using?

I know this is a problem, but in my opinion this should not
be the duty of ScummVM to fix since it will happen with any
game on new, fast computers regardless of the engine
running it. The easiest way to fix this, I've found, is to
limit the data transfer rate between your computer and the
MT-32. Programs like moslo will allow you to do this by
slowing everything down to more accurately emulate an older
computer, or a better solution if you're able to do it is
to lower the baud rate to 1200bps or less (if it doesn't
cause issues with hanging instruments) so that SysEx
commands arrive to the MT-32 at a speed it can handle.

Logged In: YES
user_id=790527

I'm using a USB MIDI cable, with Mac OS X 10.4.4. Since I'm using Mac OS X,
solutions like MoSlo aren't possible; I can't slow down my system.

I disagree, incidentally, that it's not the duty of ScummVM to fix. The purpose
of ScummVM is to make these games playable on newer computers and
newer operating systems than they were originally designed for;
incorporating a fix like this seems as though it would be a useful part of that
goal, similar to emulating sound chips that the user doesn't have, resizing the
graphics beyond their original size, and so on.

Logged In: YES
user_id=790527

I forgot to add, I've checked and I don't seem to be able to slow down the speed
of my MIDI cable, either.

Logged In: YES
user_id=1103943

I understand that it is ScummVM's goal to make games
playable on new systems, but my point was that it is not
its duty to solve issues which lie beyond the scope of the
games themselves. You are having a specific issue tied to
the use of a USB MIDI cable, which would affect you even in
DOSBox or with VDMSound. The solution must obviously be
found on your end, not by complicating the emulator further
to create a fix for a specific and rare circumstance.

If ScummVM were to include such a pause, it would be quite
difficult to implement (if I remember correctly -- it has
been awhile since I have looked at the code) because the
MIDI parsing occurs in 'real-time'; that is to say, the
data is parsed, and the commands are immediately sent to
the appropriate music/MIDI driver. Adding a pause between
every SysEx command would be a bit of work.

Even if I am incorrect in my recollection and it would be
fairly simple to implement into the appropriate MIDI driver,
you must also remember that other people will be using
various other synths (software and hardware) with the same
driver. Inserting a pause could cause all sorts of problems
for them, from hanging notes to instruments missing timed
queues, etc.

I sympathise with your problem, though, as it is one I have
had using my MT-32 via a MIDI -> serial port -> USB cable.
I am not presently in the same location as my equipment,
but when I return in a few weeks I will try to look into
how I eventually solved the problem and see if I can be of
any assistance to you. Best of luck.

Logged In: YES
user_id=12935
Originator: NO

While we can't really insert a pause after *every* SysEx, it should be possible to insert some delays into sysex sequences that get "fired" during engine startup. Some engines already do this, I think.

In fact I just checked and the BASS engine already contains some such delays. I added a few more, but that's really all we can do about this, I am afraid.

Logged In: YES
user_id=23042
Originator: NO

This bug also occurs on my MT-32 connected directly to my ensoniq 1371 sound card (some old model soundblaster) with today's svn scummvm. So, an USB-MIDI cable doesn't appear to be the cause.

(For the record, running 64 bit Linux.)

Logged In: YES
user_id=991728
Originator: NO

I ran into the same problem when I was trying to add MT-32 support for Kyrandia engine today.
Got an Creative Soundblaste Live and my MT-32 conneted to it. On Linux/AMD64.

Logged In: YES
user_id=23042
Originator: NO

For reference, this was solved in Pentagram in audio/midi/LowLevelMidiDriver.cpp, sendMT32SystemMessage() by keeping a 'next_sysex' timer that is set to now+40ms after sending each sysex. Just before sending a new sysex message, it delays until the next_sysex time. This appears to be sufficient delay to prevent the overflow.

http://pentagram.svn.sourceforge.net/viewvc/pentagram/pentagram/trunk/audio/midi/LowLevelMidiDriver.cpp?revision=2010&view=markup

Moving this solution to scummvm could be done by creating a wrapper sysEx function in MidiDriver that handles the delay (possibly based on the 'true mt32' config option) and calls the current low-level sysEx function in the individual midi drivers.

Logged In: YES
user_id=23042
Originator: NO

For now, I increased the delay already in place in BASS to 40ms. This removes the overflow during BASS startup for me. It would still be nice to move this up to MidiDriver, of course, so other engines benefit as well.

Logged In: YES
user_id=554178
Originator: NO

I'm new with this (today I just started my MT-32) and I've seen this issue in BASS. So maybe the 40ms delay isn't enough? I'm using a USB-Midi adapter.

Logged In: YES
user_id=12935
Originator: NO

Quite possible. Feel free to experiment with this and see whether you can fix t he issue!

Also, I recently re-hooked my own MT-32 (also via USB-MIDI-adapter). So maybe I can help out a bit, too, although my spare time is rather limited these days :/