ScummVM and MT-32
Moderator: ScummVM Team
ScummVM and MT-32
I have this weird problem: ScummVM does play music through my MT-32 but it sounds wrong. This is easy to spot on Space Quest 3 intro for example, once the credits start.
I don't think it's my USB to MIDI cable because I can play this tune in hoot and it gets it right. So perhaps ScummVM is not sending SysEx messages properly? Too fast for example? Is there a way to configure that - packet size, delay in miliseconds?
I did find this bug report, closed now: http://sourceforge.net/tracker/index.ph ... tid=418820
Seems like the E-MU 1x1 link might be the culprit (this is the one I have, and I'm also using Windows 7 x64) but as I said, hoot does get it right.
By the way, why is FluidSynth gone now? It was considerably better than Microsoft GS.
I don't think it's my USB to MIDI cable because I can play this tune in hoot and it gets it right. So perhaps ScummVM is not sending SysEx messages properly? Too fast for example? Is there a way to configure that - packet size, delay in miliseconds?
I did find this bug report, closed now: http://sourceforge.net/tracker/index.ph ... tid=418820
Seems like the E-MU 1x1 link might be the culprit (this is the one I have, and I'm also using Windows 7 x64) but as I said, hoot does get it right.
By the way, why is FluidSynth gone now? It was considerably better than Microsoft GS.
- envisaged0ne
- Posts: 162
- Joined: Mon Nov 01, 2010 9:17 am
- Location: United States
And this is exactly how I have it set up
A small update: found the EXE files, tried DOSBox 0.74 (the standard build). It gets it wrong too but the game startup is way faster than what it takes hoot to initialize MT for the tunes of this game.
So here's what I did - I power-cycled Roland, run hoot, made sure it set the banks properly and is playing. Then I run the game in DOSBox again and this time it works perfectly. So obviously it runs too fast, I'm going to try and reduce the cycle count, see what that does.
ScummVM however sounds always the same and always wrong, doesn't matter if it's fresh load to MT or after hoot.
EDIT: I set DOSBox to "cycles=fixed 250", at which point the game is unplayable but it does fix almost all music issues. Almost, not yet completly, as running hoot does.
So I would hazard a guess that there needs to be a considerable delay between SysEx packets. Looking for an answer I found, among other things, this: http://www.midiox.com/cgi/yabb/YaBB.pl? ... 1212588731
Guys who use MIDI equipment have similar problems and the answer is to limit both packet size (chunk of data sent at any one time via MIDI) and have a delay after that. Could those parameters be added to ScummVM, for SysEx data at least?
A small update: found the EXE files, tried DOSBox 0.74 (the standard build). It gets it wrong too but the game startup is way faster than what it takes hoot to initialize MT for the tunes of this game.
So here's what I did - I power-cycled Roland, run hoot, made sure it set the banks properly and is playing. Then I run the game in DOSBox again and this time it works perfectly. So obviously it runs too fast, I'm going to try and reduce the cycle count, see what that does.
ScummVM however sounds always the same and always wrong, doesn't matter if it's fresh load to MT or after hoot.
EDIT: I set DOSBox to "cycles=fixed 250", at which point the game is unplayable but it does fix almost all music issues. Almost, not yet completly, as running hoot does.
So I would hazard a guess that there needs to be a considerable delay between SysEx packets. Looking for an answer I found, among other things, this: http://www.midiox.com/cgi/yabb/YaBB.pl? ... 1212588731
Guys who use MIDI equipment have similar problems and the answer is to limit both packet size (chunk of data sent at any one time via MIDI) and have a delay after that. Could those parameters be added to ScummVM, for SysEx data at least?
Last edited by dknute on Wed Jun 15, 2011 10:41 pm, edited 1 time in total.
- envisaged0ne
- Posts: 162
- Joined: Mon Nov 01, 2010 9:17 am
- Location: United States
Aaand I just found out that SQ3 might not be the best way to test. According to this page anyway: http://en.wikipedia.org/wiki/List_of_MT ... uter_games
If the footnotes are correct then SQ3 is one of the games that needs the earlier model of MT to work properly. I actually have CM-64 and it's based on the older model hardware. But then again, how does hoot makes it go away once run?
If the footnotes are correct then SQ3 is one of the games that needs the earlier model of MT to work properly. I actually have CM-64 and it's based on the older model hardware. But then again, how does hoot makes it go away once run?
- envisaged0ne
- Posts: 162
- Joined: Mon Nov 01, 2010 9:17 am
- Location: United States
Uh, no. There were two major revisions of MT-32, and there are some minute differences between them. The older one can apparently be abused in some ways and this is not compatible with the newer models.
Also, CM-64 is CM-32L + CM-32P, and CM-32L _is_ MT-32, just without the LCD. Please don't dismiss my problem like it was some sort of different and incompatible hardware issue.
Also, CM-64 is CM-32L + CM-32P, and CM-32L _is_ MT-32, just without the LCD. Please don't dismiss my problem like it was some sort of different and incompatible hardware issue.
Just to be sure, in the ScummVM options you did set "True Roland MT-32 (disable GM emulation) on the MT-32 tab, didn't you.
As far as DOSBox is concerned, the SVN addresses certain errors in sending sysex data to the unit. According to Qbix:
As far as DOSBox is concerned, the SVN addresses certain errors in sending sysex data to the unit. According to Qbix:
In the SVN of DOSBox there is now some code that will insert delays when writing to your real MT32. (you can enable it through the midiconfig parameter)
This should make DOSBox is little more friendly with games that write too fast and cables that don't buffer.
I'm using a CM-32L which is essentially a MT-32 and I don't have any problems.
The thing is, if I remember correctly, NOT to select MT-32 but "Windows MIDI" and your MIDI interface (I use a cheapo USB-thingy) and check "True Roland".
The thing is, Space Quest 3 sounds fantastic in ScummVM and allows you to play it without any problems - even including the few digital effects (like "Where am I?") and, well, the EGA undithering, if you like that.
In my opinion, these Sierra games should be played with ScummVM not with DOSBox.
The thing is, if I remember correctly, NOT to select MT-32 but "Windows MIDI" and your MIDI interface (I use a cheapo USB-thingy) and check "True Roland".
The thing is, Space Quest 3 sounds fantastic in ScummVM and allows you to play it without any problems - even including the few digital effects (like "Where am I?") and, well, the EGA undithering, if you like that.
In my opinion, these Sierra games should be played with ScummVM not with DOSBox.
Trust me, I've tried pretty much all combinations of the MIDI settings. Tested with GM MIDI, that's even worse obviously. Disabled GM MIDI, used Roland interface. I can see the LED blinking so it is talking to the device (and of course the volume knob does something), so I'm sure it's not a broken emulation I'm hearing. I even tried with and without GS mode, no change as far as I can tell. I'd rather use ScummVM too, it's less hassle than emulating DOS and no need to keep the executables, but alas...
Thanks for pointing out that DOSBox SVN fix. I found 25th of May build which has it in so I'm going to try that in the evening.
I'm starting to think that both my MIDI interface (as it boasts extremly low latency) and Windows driver layer add some buffering on their own. And the result is some SysEx packets get sent together, without proper delay. Some people claim that the newer MT-32 hardware can work with MIDI full-speed but this is clearly not the case.
I do have another, el-cheapo USB MIDI cable but that one is broken beyond words. It mangles all SysEx messages, doesn't work properly with Windows 7 x64 either. I got it to work, more or less, on my netbook's XP but only for pure General Midi stuff.
I will also try booting one of those Linux-on-CD things, and see if I can get any interesting results. The "hoot workaround" for DOSBox isn't perfect since it will not work for games that change instruments after initial loading.
Thanks for pointing out that DOSBox SVN fix. I found 25th of May build which has it in so I'm going to try that in the evening.
I'm starting to think that both my MIDI interface (as it boasts extremly low latency) and Windows driver layer add some buffering on their own. And the result is some SysEx packets get sent together, without proper delay. Some people claim that the newer MT-32 hardware can work with MIDI full-speed but this is clearly not the case.
I do have another, el-cheapo USB MIDI cable but that one is broken beyond words. It mangles all SysEx messages, doesn't work properly with Windows 7 x64 either. I got it to work, more or less, on my netbook's XP but only for pure General Midi stuff.
I will also try booting one of those Linux-on-CD things, and see if I can get any interesting results. The "hoot workaround" for DOSBox isn't perfect since it will not work for games that change instruments after initial loading.
- MusicallyInspired
- Posts: 1138
- Joined: Fri Mar 02, 2007 8:03 am
- Location: Manitoba, Canada
- Contact:
You can get the digital effects in DOS/DOSBox too with the proper SNDBLAST.DRV driver that wasn't included with the game.balpat wrote:The thing is, Space Quest 3 sounds fantastic in ScummVM and allows you to play it without any problems - even including the few digital effects (like "Where am I?") and, well, the EGA undithering, if you like that.
In my opinion, these Sierra games should be played with ScummVM not with DOSBox.
It works perfectly in hoot so I think I can rule out hardware failure
Also, just tested, DOSBox SVN with MT-32 fixes works perfectly. Just like hoot, when SQ3 starts the LED on CM unit lits up and pretty much stays like that until all the SysEx data is transmitted. In reality it probably flashes but too rapidly for an eye to notice. The only hint is it's sligtly dimmer than usual.
Now, with ScummVM you can easily tell it flashes. When it's on, it's quite bright too. So there is a difference in how the data is beeing seen by the unit.
In case anyone cares, my DOSBox settings are:
cycles=auto 5000 80% limit 25000
mpu401=intelligent
mididevice=default
midiconfig=1 delaysysex
That "delaysysex" is important. Will not work properly without it and it's exactly what the SVN change is all about.
Also, just tested, DOSBox SVN with MT-32 fixes works perfectly. Just like hoot, when SQ3 starts the LED on CM unit lits up and pretty much stays like that until all the SysEx data is transmitted. In reality it probably flashes but too rapidly for an eye to notice. The only hint is it's sligtly dimmer than usual.
Now, with ScummVM you can easily tell it flashes. When it's on, it's quite bright too. So there is a difference in how the data is beeing seen by the unit.
In case anyone cares, my DOSBox settings are:
cycles=auto 5000 80% limit 25000
mpu401=intelligent
mididevice=default
midiconfig=1 delaysysex
That "delaysysex" is important. Will not work properly without it and it's exactly what the SVN change is all about.
- MusicallyInspired
- Posts: 1138
- Joined: Fri Mar 02, 2007 8:03 am
- Location: Manitoba, Canada
- Contact:
Yes, you can. If you use SNDBLAST.DRV (the proper one, there are others that don't work) you'll get stereo Adlib music and digital sound effects. If you use the proper MTBLAST.DRV you'll get MT-32 music with digital sound effects.balpat wrote:Yes, but you cannot choose two soundcards, can you? So it's either soundeffects (for which you have to find a working .DRV as it wasn't included) or MIDI-music.
Turns out Fluidsynth is still present, just not in x64 version. It really should be pointed out on the download page that the 64-bit Windows build is inferior.
Back to the main problem: I couldn't find any live CD/DVD Linux that would come with ScummVM and I don't want to do a full install just to test it.
I did test the SVN DOSBox quite a bit and I'm very happy with the results - as far as MT-32 is concerned anyway. Works well with other (non-adventure) games too so I will definitely keep it.
My SQ3 came with SNDBLAST.DRV (and of course MT32.DVR) but not MTBLAST.DRV. I did found it however in my SQ1 SCI remake so I'm going to modify RESOURCE.CFG by hand and see if it works.
BTW, another thing I noticed is different sound in QFG3 opening sequence, the one that glowing sword makes. Both Microsoft GS and Fluidsynth have a Sci-Fi like sound effect here and a true SC-55 (CM-300 in my case) uses a different sound. But now I'm not sure which is right, perhaps it's again wrong on the real hardware due to a missing or wrong intrument bank switch? I'll have to dig up the executables for this one as well to test under DOSBox.
Back to the main problem: I couldn't find any live CD/DVD Linux that would come with ScummVM and I don't want to do a full install just to test it.
I did test the SVN DOSBox quite a bit and I'm very happy with the results - as far as MT-32 is concerned anyway. Works well with other (non-adventure) games too so I will definitely keep it.
My SQ3 came with SNDBLAST.DRV (and of course MT32.DVR) but not MTBLAST.DRV. I did found it however in my SQ1 SCI remake so I'm going to modify RESOURCE.CFG by hand and see if it works.
BTW, another thing I noticed is different sound in QFG3 opening sequence, the one that glowing sword makes. Both Microsoft GS and Fluidsynth have a Sci-Fi like sound effect here and a true SC-55 (CM-300 in my case) uses a different sound. But now I'm not sure which is right, perhaps it's again wrong on the real hardware due to a missing or wrong intrument bank switch? I'll have to dig up the executables for this one as well to test under DOSBox.