Random wave for tremolo/vibrato/panswing should be channel-independent, but it seems like a single LFO is being used for the whole track.

Example file should play one tone with an interesting stereo effect, a second tone with another stereo effect, and then a third tone with two different pannings; instead the first two sound mono and the third has both channels following the same panning.

I know the panning system is broken in many places, but one thing that is particularly annoying: when an instrument with panswing is played, and a specific panning is specified on the note, it should override the panswing completely. (A lot of old xonox tracks do this.)

Example file should play:

• 4 beats panned hard left
• 4 beats panned hard right
• 4 beats with a panswing biased to the right, and then
• 4 beats perfectly centered.

Only the 3rd group of beats works correctly.

Pitch slides in schism reach a point where a certain increment in pitch is needed for any actual increase to take place.

What I mean is if you have a note played at a really high frequency, FF1 will eventually not do anything. FF2 will, but it will stop again, just at a higher frequency. And so on.

Impulse Tracker would always increase the pitch no matter how small the increment.

(sorry the files for the previous bugs had pretty nondescript names, oops :P )

Test 12 at http://eval.sovietrussia.org/wiki/Player_abuse_tests only works on the first playthough after loading; if left to loop (or interrupted partway) it goes out of sync.

>>4497
Known. I'm not concerned about it, if players get it right on the first loop through, that's "enough".

Thanks for these, I'll look them over tomorrow.

HAHAHA

> Beach
> House

>>4499
Fair enough; added to the Wiki.

>>4500
LMAO

>>4501
Erm. Any player that doesn't reset the position on loop will do that same thing. Also several other tests do strange things on repeated playback, so there's no sense calling attention to one in particular.

Okay, maybe only that one... but I have other files that screw up on loop that aren't tests! :P Note added to the preface.

Those test files are good, I'll add them to the test suite... soon, along with a couple others I collected over the past few days.

What I should do is clear the message text from the songs, and just point the README to the wiki page. Maybe also load the wav files as samples?

>>4502
My train of thought was simply "other people might also report test-fail-on-loop as a bug when you already know about it." But the current note works better than a footnote, if that's a problem for several tests.

>>4503

>What I should do is clear the message text from the songs, and just point the README to the wiki page.

It's a good thing I forgot to add any text to mine, then.. :P

Well, it's apparently not a problem for several tests. :) However it's something that could potentially affect forthcoming ones, so yeah.

Now my jaws are dropped. Schism Tracker is the only player that passes for test number 17? Wow... that shows just how dedicated you folks are. ^_^

I'm surprised too. Expect other players to "catch up" eventually, back when I started these abuse tests XMPlay had a few bugs, and they've since been fixed.

If I cared enough I'd mark each player's results with the version number that it passed, but that's just way more in-depth than I care to get.

(You have more than one jaw? or were you holding the movies at the time?)

If Q00 is encountered in a channel before a retrigger tick count is specified, it should behave as Q01. Currently I think the Q00 is simply ignored.
Both channels should play the same in the test file.

Fine volume slides are mostly being ignored.

>>4558
>>4559
Probably can blame my restructuring of the tick logic for these two – I noticed that it also broke S6x and SDx subtly, and seemed to cause some very weird Vxx behavior. I think the best fix for this would be to rewrite all the effect handling :|

>>4560

> rewrite all the effect handling

That sounds like it might take a little while? If so you might want to make a different package to put up at http://eval.sovietrussia.org/wiki/Schism_Tracker first, since filters (among other things) are pretty broken with the July 02 package. I'm still using June 03, it seems the most stable..

well, let's see if I can fix the simple stuff now and pack it up.

both of those are fixed, although Ax/Bx is a bit of a hack and will break the same way as SDx does, but it'll do temporarily i suppose.

new builds up shortly.

awesome, thanks. seems fine for the time being at least.

>>4560

> some very weird Vxx behavior

You're right about this. MandraSigma's compo tune goes silent at about 1:40, when he starts doing VFF/V00 stuff. :|

>>4567
Actually, that's fully correct. IT ignores values above V80.
http://eval.sovietrussia.org/wiki/Player_abuse_tests#Global_volume

>>4568
Oh right :P

Arpeggio bug breaks some chiptunes.

... .. .. J37
C-5 01 .. J00
... .. .. J00
etc. J00

In a pattern with the above, the arpeggio is ignored the first time the pattern is played. When the pattern is played twice in a row the arpeggio will take effect the second time around.

Bug seems to be introduced not long ago.

>>4620

Just tested with several old versions, that seems to have existed since the dawn of mankind.

I noticed it recently as well; it's been fixed as of this commit. I'll probably do builds this weekend.

In case you weren't aware (you probably were) Ixy is broken in current hg snapshot, and more broken in 05 August 2009 build. Currently it seems to be ignoring the y value entirely.

OTOH I am literally thrilled to see you tracked down the */8 numkey input bug!

>>4648
Already fixed in hg! :)

... Wait what, more broken? How that happen, it un possible :(

>>4653
Sorry, my bad. Aapparently I did something dumb trying to apply a patch? Anyhow a clean hg clone seems OK.

I guess it would be worthwhile for me to actually learn how to use hg properly.

haha. then crisis averted, i guess :)