Menu
▾
▴
#6686 SCI: General MIDI using SC-55 misses instruments
I thought I would share an issue I discovered with version 1.7 of the Win32 software that was just released. Any game that utilizes General MIDI and using a real SC-55 the music is being mapped only to channels 10 through 17 on the device, thus causing instrument errors in the games. An example would be King's Quest VI; the title music is missing some trumpet sounds and in-game MIDI music and sound effects are either missing or are incorrect. I downgraded back to version 1.6 and all MIDI channels were once again mapped correctly on my SC-55. Thank you.
Sorry; channels 10 through 16. Typo.
natedavis82: Can you replicate this with an game using MIDI music other than SCI engine games?:
http://wiki.scummvm.org/index.php/Engines#Complete_Engines_in_the_Latest_Stable_Version
i.e. I am trying to work out if this is a regression in the common MIDI or midi output code, or a problem specific to the SCI engine sound/music code.
Thanks for that suggestion. SCI appears to be the issue. The music plays on channels 10 through 16 while other engines play on 1 through 10. In version 1.6 SCI music plays on channels 1 through 10. I may have misspoke when I said "all" channels in the original post as this is not the case.
Apart from this, are you capable of compiling ScummVM from source code?
http://wiki.scummvm.org/index.php/Developer_Central
http://wiki.scummvm.org/index.php/Compiling_ScummVM/MinGW
If so, then it would be best if you could do a git bisection to locate the specific commit between v1.6.0 and v1.7.0 release which introduced this.
If you are not capable of doing this, then I can look at preparing some test builds to allow you to do this... but this will be more painful and slow than if you can do this.
I'm sorry, I do not know how to compile.
10-17? That's strange. GM should use only 10-15 during the music at the KQ6 Sierra logo.
The new MIDI channel mapping code fills channels from the last one down, so if it fills up 10-17 (or 10-15), then channels aren't the limiting factor. Polyphony also isn't particularly tight there, so that seems an unlikely factor too.
Can you attach your ScummVM configuration file?
In version 1.6 the music plays on channels 1-10 and all instruments play correctly. In version 1.7 the music plays on 10-16 and a trumpet sound is missing at the title screen. Also, in certain areas of the game sound effects and music do not play correctly. I have uploaded my configuration file.
I just noticed your forum post saying that a GS Synth does work. This probably means you have "Roland GS Mode" enabled in the MT-32 settings tab. Disable that if you have a GM device hooked up.
I did as you suggested and it did not fix the issue. Music is still being played on channels 10-16.
Setting bug to pending (user response needed).
natedavis82: OK. I think we need to bisect and locate the exact code change where this regression was introduced. This would be alot faster if you could compile and test yourself, but otherwise I can do a manual compilation and provide a build for you to test, you indicate if it shows the bug or not... and we repeat in a binary search until we locate the regression point (probably this will take about 4-5 test builds.).
I'd be happy to help in any way I can. I have never compiled before, but I think I understand what's involved. Do I simply download previous source code and build it for Win32? Did I say that right?
Fairly close! Detailed instructions for getting the code and then compiling it into a binary to run are given at http://wiki.scummvm.org/index.php/Developer_Central, specifically as
http://wiki.scummvm.org/index.php/Git#Retrieving_the_code and http://wiki.scummvm.org/index.php/Compiling_ScummVM/MinGW
I really suggest you read these as they should give fairly clear guidelines.
I will give you a quick walkthrough assuming you are on Win32 (If you don't understand anything I suggest Wikipedia or Google for it as there is good quickstart documentation for most of these tools):
First download and install Git from here: http://git-scm.com/download/win
This is the tool we use to manage and work with source code revisions.
From the Git Bash command line, change to a "temporary" directory on say
your desktop using "cd <directory path="">". This is very similar to the
Windows cmd shell commands, but it is Unix Bash shell.</directory>
You can then get our source code using the command:
"git clone git://github.com/scummvm/scummvm.git"
After a few minutes of downloading and unpacking you will have a new
directory called "scummvm" in your temporary directory. This is our
full source code and revision history as a Git repository, which is
just a normal directory (with some special extra files hidden in a
folder called .git at the top folder).
You will need to install the MinGW (Minimal GCC (GNU C/C++ Compiler) for
Windows) from here: http://www.mingw.org/
and the relevant libraries.. Install these as per the guide I gave earlier:
http://wiki.scummvm.org/index.php/Compiling_ScummVM/MinGW
When you are ready, open a MinGW Bash shell, then use the "cd <directory>"
command to change to the temporary folder and then "cd scummvm" to move into
the scummvm folder.</directory>
You should now be able to compile the source code using the command:
"./configure && make clean && make"
This will try to "configure" i.e. run script to detect your operating
system, machine type, find the required libraries, any optional libraries
etc. and then "make" will compile the code (The "make clean" just cleans
up from previous or failed compile, so just a precaution).
If everything goes well, a scummvm.exe will end up in the final folder.
You may need to copy a SDL.dll from the released Win32 version folder
to this folder to run this.
You can run this by typing ./scummvm.exe at the MinGW command line or
browsing to the folder and double clicking on the executable.
Once you can do this, you can do a Git bisection (binary search). See:
http://git-scm.com/docs/git-bisect
To see the commit history use gitk... You need to start the bisection using "git bisect"... then mark a bad commit (which is easy as you are currently on the latest revision of the master branch (HEAD) which from your previous compile still shows your bug and thus is BAD" ... so you mark that as bad using "git bisect bad" then change to a possible good commit using "git checkout <commit sha1="" id="">" ... The id is the long hexadecimal value associated with each commit in the gitk window.. Choose 6e3510ac6154783a99b58bfae83c86145954435f to start. Then do a compile (./configure && make clean && make) as before... Then test this scummvm.exe. If the bug is absent, do "git bisect good".. otherwise you will have to mark it as "git bisect bad) and go back further with "git checkout <older sha1="" id="">" (but this should not be necessary).</older></commit>
Once the bisection has a good and bad commit... it will do the checkout automatically selecting the commit in the middle (thus binary search as each step halves the number of commits left in the good to bad range) and inform you. You do the compile... and test and then mark the commit as bad (has bug) or good (bug missing) with "git bisect bad/good"... the bisection will recalculate and give you another commit to compile and test... be careful to be accurate as it will switch a few times probably.
When you get down to a single good and bad commit, it will print "First Bad Commit is... ". Copy that information and post it here.
Thanks for the detailed instructions! I like a good challenge so I hope I can find the problem for you.
If you get stuck, I have also now done a manual compile of a possible bisection point:
http://buildbot.scummvm.org/snapshots/other/scummvm-i586-mingw32msvc-8cc82d0a.zip
http://buildbot.scummvm.org/snapshots/other/scummvm-i586-mingw32msvc-857d2e7b.zip
If you could test these two builds, and we are lucky / right, then this will be the point of regression.
You're good! 8cc82d0a maps correctly to channels 1 through 10! 857d2e7b maps to 10 through 16.
You also be able to get more information on the difference purely from v1.6.0 and v1.7.0.
You will need to run both from a command line window and use "scummvm -d 4 --debugflags=Sound" or similiar before running the SCI game to test. See:
http://wiki.scummvm.org/index.php/Debugging_ScummVM
You can also change the debug level and debug flags can be listed and enabled and disabled from the interactive console in game using CTRL-D, then typing "help" to list commands and "debugflag_list" to list the available debug output channels. The actual detailed debug logs is dumped into the command window as standard output... This can be redirected to a file in either Windows or the MinGW shell... Google for how to do this.
Sorry. CTRL-Shift-D in SCI. It does vary to avoid conflicting with the engine keyboard usage, but is normally CTRL-D.
Not really good... Just an educated guess as seen from 857d2e7b's commit log:
SCI: Rewrite MIDI channel remapping
This adds MIDI state tracking to allow channels to be temporarily
unmapped and later re-mapped when there are free device channels
available again.
and the 8cc82d0a is the previous commit to engines/sci/sound...