Schism Tracker development

Note: Because Schism Tracker started a few years ago to use the CWT TrackerVersion ID 0x4000 (after a 0xf000 bitmask) for S3M and IT modules which originally BeRoTracker was using since 2004 for S3M modules (0x4100), BeRoTracker is now using a new CWT TrackerVerson ID 0x6000 for S3M "and" IT modules, which means from now on all saved S3M and IT modules will have the new CWT TrackerVersion ID.

Proposal:

1. So Schism Tracker should check now at S3M for 0x4100 and 0x6000 and identify these CWT values as BeRoTracker, and at IT the same only for 0x6000.

2. Optional: Schism itself should avoid 0x4100 as the whole CWT value, so that the S3Ms are explicit distinguishable, with which tracker these are created.

This information has also been added to my lists of tracker IDs:

http://wiki.openmpt.org/Development:_Formats/IT
http://wiki.openmpt.org/Development:_Formats/S3M

Ooh, fun stuff.

> Schism itself should avoid 0x4100 as the whole CWT value

That'll very likely happen, since 0x100 in Schism's weird timestamps indicates a version built on some specific day in 2010 or so.

• Complexity: Trivial
• Priority: Low
• Status: Accepted

In the Windows build 20110101, playing one note while using S91 to set it to surround will cause the following notes in the same channel to also be played in surround, even when those notes use a sample that has default panning. In Impulse Tracker, a sample's default panning would instead override the S91 from the previous note.

For example, given the following samples:

01 Bass Drum (with default panning on and set to 000)
02 Claps

The following pattern should play a left-panned Bass Drum, then surround Claps, followed by another left-panned Bass Drum:

C-5 01 .. .00
C-5 02 .. S91
C-5 01 .. .00

Instead, the second Bass Drum is in surround. I've attached a file demonstrating this.

Huh. That's an easy fix.

(at least, it will be once I figure out why recent Windows builds won't run at all)

• Category: Playback
• Complexity: Trivial
• Priority: Normal
• Status: Accepted

The lenght of a row is (1 + Row Delay) * (Speed + Tick Delay). Schism simply adds up tick delays, which is wrong. Just check the last note in the attached example...

*lenght = length

Also make sure that this plays correctly if you fix this, SONG_FIRSTTICK should be set every "Speed + Tick Delay" ticks...

Ah yes, the pattern delay thing. That's also why arpeggio doesn't quite play right with very strange combinations of tick and row delays. Never did bother fixing it though.

I need to clone myself ._.

• Category: Playback
• Complexity: Trivial
• Priority: Low
• Status: Accepted

Also, when importing an S3M file, you should probably not import SE0 commands, since ST3 ignores them, but if the leftmost row delay command is SE0 in IT, it will consider this command and ignore all commands to the right of it...

>>1562
I've been thinking about this. Wouldn't that screw up S00 later on if someone wanted to do that intentionally? For example pattern 0 has SC3 to "prime" the S00 to cut a note off later, pattern 1 uses S00 to cut the note off, pattern 2 has SE0, and then pattern 1 plays again and S00 doesn't do anything.

I know it's a rather contrived example, but who knows. Maybe it'd be better to replace SE0 with some nonzero value that has no effect. S1F maybe? (S10/S11 are the gliss switch, so S1x beside that are no-ops AFAIK)

I don't see how that would be a problem. Schism does S3M memory "wrong", anyway: S00, together with many other commands, uses the last non-zero parameter as memory. For example, KC3 followed by S00 is equivalient to KC3 followed by SC3.

>>1574
I mean for the purposes of re-export to S3M / compatibility with other players.

Thinking of it, it is probably not worth taking care of that anyway - since you'd still have to keep many other things in mind when emulating ST3 behaviour, such as channel ordering ("left" channels are evaluated first, then "right" channels, so the "first" channel is not only the leftmost channel in the pattern).

I s'pose.

I think this was suggested earlier, but here goes anyway:

>On F5, the info page, you can change your channel resolution with pg-up/dn (Hit tab twice before doing this)

This reminded me of eventually having some presets... If possible. Changing F5's view with one keybinding to fit the needs of a chiptune to that of a full blown 64channels madness orchestral piece.
Maybe one default (how it currently is) 3 predef presets and 2 that can be user defined? This could be done with ctrl-shift-0 to 6, similar to in F2.

This would take away the job of tabbing and paging up and down, which took me some years to get accustomed to.

>>1571
You can save last F5's configuration with F12-"Save all preferences". It isn't presets as you described them but is enough in most cases.

Hm... What do you guys think about commandline option for loading different config files? OP will be able to do something like that:

$ schismtracker -c ~/.schism/chip.conf
$ schismtracker -c orchestral.conf
$ schismtracker -c /dev/urandom

Or to create some .sh/.bat/.lnk files for it or whatever.

(And some gui for changing config files on the fly.)

I like this keybinding idea, and now that it's been mentioned I don't know how I never thought of it myself. I'm switching stuff around on that screen all the time.

It might be better to copy the way the envelope presets work, though - Ctrl-num to save and Shift-num to load. (and now that I think about it, Ctrl-Shift-num should load for symmetry with the pattern editor, but it saves. Hrmmm.)

• Category: User Input
• Complexity: Trivial
• Priority: Normal
• Screen: Info Page, Instrument List
• Status: Accepted

No idea what's going on here. My build from 2011-08-13 plays this file fine. Current build doesn't play channels 6 through 13 (all the same instrument). 18 and 19 are muted, as intended.

2012-01-05 build plays correctly

sadfjkasdjfklj what

it's that specific instrument

• Affected Version: 2012-02-16
• Category: Playback
• Complexity: Trivial
• Priority: High
• Status: Accepted

Latest hg build ignores instrument if value of it's last node of Volume Envelope == 0.

That build should ignore first chord in attached file and play second. I didn't tried it though, too lazy to build schismtracker from hg again.

Hm. Thanks, I'll try to make time to fix that :/

I think this patch fixes it.

Both modules posted in this thread plays as they should.

Is this even correct place to mess around with the volume?
_process_envelope function never asks about volume in it's body except this one place.

Seems like it should work. I PROMISE I'll play with it next week. :)

If you mute some channels in F11, and go to F2 and press alt-F10 to unmute, the channels you just disabled in F11 should stay muted, but Schism unmutes everything to the settings that came when you last saved the file.
When you do nothing after unmuting channels in F11 and save the file and reload it, then it honours your muted and unmuted channels.

The correct behaviour is of course what you mute in F11 stays muted, unless you unmute it again in F11, regardless of save states.

Nope. The correct behavior is what Impulse Tracker does, and is what most people are used to - once you have unmuted a channel, it is added to the set of channels that should be unmuted when you toggle a channel solo. Doing it otherwise is less straightforward to handle and more confusing to work with if you've gotten used to IT style.

• Status: Rejected

I did check in Impulse Tracker before I started this thread but maybe I wasnt clear enough. I am not talking about toggling individual channel solo and adding them, because that is what happens indeed.

Open a song (or start a new one), e.g. which has active channels 1-16, rest is muted. Now if I go mute channels 5-8 in F11 and go back to F2, channel 1 and press alt-F10 to toggle solo channel, channel 1 is solo'd. If I press alt-F10 again, then channels 1-4 and 9-16 should be activated again. Schism activates everything 1-16. This is not IT behaviour.

Also, in the example, when I would go to channel 5 (or 6,7,8), and solo and unsolo it with alt-F10, Schism would also add 6-8 to the active channel list.

>if you've gotten used to IT style.

Never used anything else, that's why!

Ohhhhhh!

Huh, I don't think I even considered this.

Well then.

• Complexity: Trivial
• Priority: Low
• Status: Rejected → Accepted

long-standing bug: loading stereo samples sucks. Trying to load the left channel only of a 16-bit sample loads half from the left sample and then half from the right. 8-bit samples are not affected.

It would also be nice to have other options for loading stereo samples (such as loading both channels as mono) but that's less important.

Yeah, that's a thing.

There's an item ....... somewhere ...... on my todo list about completely overhauling the sample loading. I'd like to have it just load them as stereo, and add a keybinding to split the channels.

• Category: File I/O
• Complexity: Moderate
• Priority: Normal
• Screen: Sample List
• Status: Accepted

I created a new file, added "000" in top of Order List and saved it.
Size of file was 208 bytes.

Then I loaded and saved it again.
Size of file became 8 bytes larger.

I repeated loading/saving that file for some time, and now it's size is one kilobyte.

That is intentional - it's writing session timestamps logging when and how long you were working on a given song. Impulse Tracker writes this info as well, and so do recent versions of OpenMPT. You can extract that with a tool such as timestamp.py which comes in Schism Tracker's source package.

How can I clean it out?

Also:

$ ./timestamp.py supersize.it
Traceback (most recent call last):
  File "./timestamp.py", line 41, in <module>
    para_min = min(filter(None, para))
ValueError: min() arg is an empty sequence

I suppose you could strip those by saving in an older version of Schism or OpenMPT, but I'd check to make sure it still plays right. Aside from trying to cram a file into a few hundred bytes for a compo or something, why would you want to delete that, though? It's worthwhile data and doesn't take much space.

Just pushed a fix to not break the script with a file that has nothing except history data in it.

>trying to cram a file into a few hundred bytes for a compo

This reason is good enough for me.

Note that OpenMPT also has a "Clear History" function, which will remove all but the current timestamp, so you'll still have an overhead of 8 bytes. Strictly speaking, you have an overhead of 10 bytes, because there's still the number of history entries that is saved and most trackers / players don't like it when that number is missing, although there is a header flag that tells whether this number is present or not, but they ignore that flag.

I've always thought that if you're trying for insanely tiny file size, a custom tool would be much better anyway than just saving it in a tracker. You can take advantage of a ton of weird tricks with the file format that way. (e.g. overlapping chip sample data with patterns, shoving things into the channel settings in the file header, and so on)

Would it be a lot of work to implement the following:
Search for patterndata that is selected and replace it with clipboard data? It's sort of like the same as searching for string A and replace them with B.

Lets say I have a song with 100 patterns all with a bassdrum channel. But this bassdrum channel is in one pattern on channel 01 and in other patterns on another channel. I want to make a big change to the bassdrum pattern data. Lots of work to browse and find the data to be replaced.

e.g. So I select and copy a block of 16. A part where the bassdrum makes a filter slide Z00-Z7F, and it also have some random volume values. I copy this and now I select the part of the pattern where I also want my clipboard to be. However, every occurence within all patterns that match the selection will be replaced by the clipboard. Awesome.

What is more important than implementation is whether dev and others users would find this useful :) I for one would!

Maybe. I know I have gotten by just fine without ever having it though, so I don't know how useful it might be. Probably once ever did I think "you know, a search-notes feature would be handy here".

• Complexity: Difficult
• Priority: Low
• Screen: Pattern Editor
• Status: Acknowledged