I make it a duty to test new schism releases every once in a while. I've found a few bugs in the october 16 release.
2. Multi out doesn't seem to detect panned channels properly. See : http://sovietrussia.org/scdev/res/350.html
I posted my test song at the end of this thread. Only channels panned hard left or hard right come out as stereo. Beware of the crappy test song.
As usual, Schism makes my life better. Have a nice day.
2. How should the stereo check work? Right now, it walks the pattern and looks for stereo samples, or more-than-one change in panning (per channel). Is something wrong with that?
2. I often use default pan on instruments. Seems this is not detected. Works well when exporting without using multi-out.
Hope this clear things a bit :)
So you're saying, you start schism, press F6 - it's an empty pattern, press F2, and resize it to 32, and press enter and schism crashes?
That's what I did and it didn't crash.
Re: panned channels, if you use a default panning, the panning still has to change once in the channel, or it'll simply be treated as a mono-channel.
If this is wrong, I can restrict the check further to only allow mono if no panning is set at all, and if no panning commands are used at all, but this would seem to me to interact poorly with s3m...
Okay, i forgot the most important step. Load a song... If i load the crap song i posted on scdev, it crashes when i increase the pattern size.
I tested with an empty pattern. Indeed when you downsize a pattern, it stops playing. It keeps on playing when you increase the pattern size.
On panned channels. The test song i posted does not even use default pan on F4 screen. I issue Xxx commands and it doesn't get noticed when using multi-out.
You can grab the craptastic song here : http://sovietrussia.org/scdev/res/350.html#594
Hope i didn't forget to specify anything this time. Sorry for the wasted time on this issue because i forgot to write critical info.
This is serious.
SDL_LockAudio() seems to be broken in a subtle way.
I've put a workaround in for now
How are you so sure Schism Tracker's code is perfectly fine and it's definitely a library bug?
Whenever I hear a developer say there's a bug in some library, my first thought is that they're being terribly arrogant about their own code. After all, SDL has a ton more people developing the library, and it gets a several orders of magnitude more use. Unless you're using an unstable bleeding-edge version of it, I really have my doubts that it's a library bug.
... Reading that over again it sounded really jackassish. I didn't mean it to be that way, but until there's a solid test case, I am hesitant to believe when someone claims that some library, compiler, interpreter, etc. has a bug in it.
> How are you so sure Schism Tracker's code is perfectly fine and it's definitely a library bug?
Frankly I'm not.
That's why I didn't use words like "definitely", but instead said "seems to be".
> I didn't mean it to be that way, but until there's a solid test case, I am hesitant to believe when someone claims that some library, compiler, interpreter, etc. has a bug in it.
I think you probably did mean it that way: that you were very angry, and you thought I was being ridiculous, which is why you framed your language to exaggerate the amount of ridiculousness that was actually there.
SDL has a shitload of bugs. Some of them we've run into (like fullscreen+dualhead), and some of them we work around (like Windib->ddraw fullscreen). Some of which we blame on windows, and some are exaggerated by monkeypatching features like clipboard, midi inout, networking, and keymap translation. Some we just sidestep neatly (we don't call the SDL_WM_* functions on MacOSX).
SDL is so buggy and poorly thought out that it simply wouldn't surprise me to find more bugs here. Here's a particularly interesting gem:
http://bugzilla.libsdl.org/show_bug.cgi?id=629
Sound familiar? Here's another one; "midi on macosx crash":
http://bugzilla.libsdl.org/show_bug.cgi?id=579
Here's a great one; apparently SDL_SemWaitTimeout simply never worked:
http://bugzilla.libsdl.org/show_bug.cgi?id=570
and here's that mess in schism/main.c which detects numlock event changes on X11:
http://bugzilla.libsdl.org/show_bug.cgi?id=599
SDL has problems just like everyone else.
Now.
This is /sc/ and not /scdev/ so I wasn't going to make a technical report here, and I haven't had an opportunity to test this thoroughly enough for a report on /scdev/ .
I made a workaround to simply stop the audio thread since the bug is triggered after the pattern data has been swapped. I'm guessing it's a cache problem- that free() is actually occurring before the thread is locked, but that the replacement of the pattern is occurring after it is unlocked.
If you want to track this down, by all means: It seems that older GCC Versions don't have this problem, but sprinking volatiles around seems to fix it as well. Setting my processor affinity also seems to help stop the bug from occurring reinforcing the idea that it's cache related.
valgrind only finds memory errors in Xlib, SDL, and frag-opt; none of which seems relevant.
First of all, thanks for fixing it.
Second, thanks for the explanations. I always like to know a bit more about schism.
>>4344
Ok. Your terse initial post (with no detail pointing to any bug reports or anything) gave the impression that you came across a problem with the code and stamped "SDL bug" on it. It's that kind of knee-jerk reaction that prompted, ironically, my knee-jerk reaction.
(It feels almost like usenet here.)
Sorry.
I'm in a terrible mood lately, and I don't like that I haven't had as much time for schism lately as I'd like...
http://bartoszmilewski.wordpress.com/2008/11/05/who-ordered-memory-fences-on-an-x86/
This sounds similar to what I'm experiencing. Putting a memory barrier near our uses of SDL_UnlockAudio() might fix it. I'll see if I can try this tonight...
Can't put "L" effect in effect column. "G", "H", "K", etc. works fine. Pressing "L" got "copy to buffer" command (usually "Alt+L").
Mac OS X.
Guessing you've probably got caps lock on or something. Shift-L is a new(ish) key that copies non-muted channels. (although it should only happen when you're actually holding shift...)
Fixed. Will do a new build shortly...
I found a bug in the latest Schism Tracker, if you select a sample and go into F2 screen and press the Q key while in any other channel than channel 1 it automatically puts the sample note into channel 1... it's killing me...