Reporting bugs

The issue tracker is where you'll want to report bugs. Create a new issue, hopefully with enough information to track down and reproduce the problem. If you can't make it happen again, the developers will have little or no chance of finding and fixing it.

• Find the smallest number of steps that cause the crash.
• Does it happen with a particular song?
• If you press a particular set of keystrokes?
• Some time after doing some steps?
• How about a particular song file format? Does it also happen to an XM file? An S3M?
• Is it dependent on a particular sample format? stereo samples? 8-bit only? 16-bit only? mixed?
• If applicable, what does Impulse Tracker do? "Bugs" that are actually reproducing IT quirks are not bugs at all.
• What version of Schism Tracker are you using? Make a note of the date at the top of the window. Did you compile it yourself, download a package from the website, or install from a package provided by your OS?
• What OS are you using: Windows, OS X, Linux, something weird? What sort of processor? (Intel, AMD, PowerPC, 32-bit or 64-bit, etc.)
• What graphics and sound settings did Schism Tracker detect? (press Ctrl-F11 right after startup)
• Did it happen with a different video driver? (press Ctrl-F1 and try the SDL Video driver)
• What MIDI hardware was detected? (press Shift-F1)
• Does it happen with different settings? (Shift-F5, F12, Ctrl-F1, and Shift-F1)

Using a Distributor

• Debian and Ubuntu users should contact Gürkan Sengün via the Debian Schism Tracker Project Page.
• Fedora users should contact Jindrich Novy.

The distro-packages tend to lag significantly behind live development. You should probably try one of the builds from the main page if you have a problem, at the very least to make sure your bug hasn't already been fixed.

If your distro's package is more than a few months out of date, please ask them to update it! Often, tons of changes can happen in that amount of time, and holding onto very old versions is a great way to make other people put up with bugs that have long since been fixed.

Tracking down problems yourself

For this, you will almost always have to build from source. The builds on the website are optimized and have debugging symbols stripped out, so they are probably not very useful for finding bugs.

1. Configure with --enable-debug. Try using --enable-ludicrous-mode as well – especially if you're on a system that isn't officially supported, this might hint at bugs that have been overlooked.
2. Run gdb schismtracker, and type run at the (gdb) prompt. Continue until it crashes.
3. After the program stops, type bt to see what broke. If it looks like garbage – lots of numbers and question marks, and nothing else – try thread apply all bt to see what might have been happening elsewhere.
4. Copy all the output to a text file, and attach that to a post on the issue tracker. Give the usual details (OS, compiler version, CPU type, blood type, height, etc.) as well as what you did to cause the crash.

If you want to go the extra step, try to narrow down what version introduced the problem. This is made somewhat easy in most cases with git bisect, assuming you used Git to fetch the source.

1. Find a build: git log and page down a bit. You can test commits pretty much arbitrarily, but pick one that's maybe a few months old.
2. Copy the hexadecimal number for the commit you picked. (b286c28d65b0 for example)
3. Check out that commit: git checkout b286c28d65b0 (for example)
4. Run make, and hopefully it will build properly. You might have to reconfigure if make dies (e.g. ./configure --enable-debug && make) as autoconf gets rather confused if you update across commits that renamed or removed files.
5. Try to reproduce the bug.
6. Update to the next commit.

• If it died: git bisect bad
• If it worked fine: git bisect good

7. Repeat steps 4-6 until Git stops and tells you which commit introduced the problem.
8. Copy the output and post it on the issue tracker. (If you're really ambitious, you might want to look through that commit's diff for the cause.)
9. When you're done, git checkout master to get back to normal.

Making feature requests

You can post suggestions to the issue tracker and see what other users think. Try to demonstrate why it would be useful, in terms of other people – not-very-convincing clichés like "Schism Tracker is almost perfect, but..." or "I would use [feature] every day" aren't thoroughly helpful. If every single "wouldn't it be cool if..." idea was implemented, Schism Tracker would become completely useless and bloated.

Some other points that you might want to address:

• What key combination might invoke this proposed feature? There aren't many "free" keys left on most screens, so anything that's going to be attached to one of them should certainly provide some obvious benefit.
• Would this feature present obvious difficulties with the file format? For example, though it's technically possible to increase the pattern length to 16384 rows, you would run into data size limits in the IT format after just a handful of notes, and most players would either reject the file as corrupt or even crash when trying to load such a file.
• Is the feature at least as useful as it is complex? Nobody wants to spend a bunch of time implementing some esoteric thing that two people will ever use.