1. Pitch envelope is slightly buggy. Basically, envelopes with duration of 1 are not played at all if the node in question is the last one before looping. Should be easy to fix. It's important to me because I sometimes use the pitch envelope to create arpeggios.
2. Exporting to additional formats. FLAC support would be useful and easy to add with external libraries such as libsndfile.
3. Minor annoyance: when saving a module, if you don't type any file extension, your song gets saved without any. IIRC Impulse Tracker automatically added the extension (.IT/.S3M) if it was missing.

Oh, and FLAC could be supported for exporting/importing samples as well.

libsndfile is pig disgusting. However, flac, ogg, and m4a samples are on my radar.

I personally would find it very interesting to be able to load entire songs as samples. That combined with some way to link samples rather than embed them into the .it file would be fantastic for making dj mixes and the like.

#3 I believe used to work, but broke when that "auto" format (which I think is a really dumb idea and has no valid reason for existing) was added.

auto makes it so if you type foo.s3m it saves as an s3m- i actually like this behavior.

adding an .it extension if none is given isn't that big a deal, is it?

>>4435
No, auto is braindead and stupid. Impulse Tracker managed to save files in a way you would expect, and Schism Tracker does it wrong. Adding more buttons doesn't make its incorrect behavior any better.

>>4436 Both behaviors are implemented.

I suppose the ITEXE behavior can be had without forcing classic mode by adding an option; I presume you suggest the ITEXE behavior be the default?

>>4437
I suggest the "new" behavior be removed. It doesn't do what people expect.

Auto's been removed.

Also added extension detection.

Idea:

It'd be convenient if, when typing a filename to save, schism inspected the filename and temporarily switched the filetype button to reflect the file extension – unless a button was explicitly clicked on. That is to say, pressing F10 and entering asdf.s3m would result in an implicit pressing of the S3M filetype button; altering the filename somehow to have an .it extension would re-press the IT button, but, selecting the S3M button explicitly and typing asdf.it would still save an s3m file.

Switching away from the page would undo any explicitly set filetype and re-enable the auto type selector.

This way, it's visually clear what is going to be saved, there's no guesswork, no extra button clicks needed, and if someone wants to save something as the "wrong" file type for some odd reason, it's still entirely possible.

>>4665

That was very similar to the behavior of the "AUTO" button that >>4437 described, that was removed at >>4441

>>4666
No it isn't. There was no visual indicator at all of what type of file was being saved before it was saved, and the auto button seemed to backfire more often than it worked properly.

Loading an S3M and saving as blah.it seemed to sometimes save S3M data, and on at least one instance it managed to overwrite an .it file with a diskwritten .wav somehow.

With this behavior (which I also think should be fully optional) you would be able to see exactly what will happen when you press enter.

I personally suggest replacing the rather useless and misleading:

> Opening /wherever/is/file.0 for writing
> Starting up diskwriter
> Diskwriter completed successfully

with something like:

> Saving to /wherever/is/file.it Format: Impulse Tracker
> (maybe some other useful info like file size, number of patterns, samples, instruments, etc...)

This way you'd know what format was saved, to what file, AND you wouldn't think you've accidentally started the diskwriter and exported the module to a .wav file.

>>4667 The one about the .wav writing occurred when the save and export pages were linked, not because of Auto. I've never experienced the rest of those problems, the way >>4665 describes it is how it was supposed to work, except for the visual indicator.

Perhaps a good visual indicator would be in the status text flash area:

• Will save in IT format
• Will save in S3M format

It could be reused when in non-auto mode to complain if the extension doesn't match the type and the extension is known to the saver:

• Warning: Will be saving in S3M format
• Warning: Will be saving in IT format

(tldr warning, proceeding to wax philosophical here)

I think what you're suggesting is using the status text in a way that degrades its purpose. Impulse Tracker usually only writes informative, but non-essential text there, to supply feedback for actions performed that were (potentially) outside the scope of what's visible onscreen, but which could potentially affect future behavior. Hence the messages for multichannel playback, cursor centralize (a bit over 50% of the time on a 64-row pattern, that option won't actually adjust anything), playback tracing, locking/unlocking the orderlist, etc. etc. etc.

Not that it's perfect; IMO there are a few cases where a dialog box would perhaps be clearer (e.g. when sample save fails for some reason, or if a song can't be loaded), and there's a couple instances where it doesn't say anything at all when it probably should, but these are the exception, not the rule. Then again, Jeffrey Lim didn't publish a human interface guideline document, so maybe there is a deeper connection than is superficially obvious. Nevertheless, in this case I think the status is a bad choice, because (a) we have the means to indicate it in a manner that's more consistent with the rest of the interface that's visually present at the time the song is being saved (i.e. the filetype buttons), and (b) warnings really shouldn't be blinked like that to begin with.

I agree with >>4669 in that the text displayed on the save page is entirely unhelpful. Visual separation from the rest of the text on the log page would be great – make it not all gray, add some extra space around it, maybe even reset the scroll position so the old text is scrolled offscreen. (Of course you could still get to it with pageup or whatever, but no one really looks at that page anyway. It's not exactly Terry Pratchett quality.) Information about the file – the file format; number of patterns, samples, instruments, etc.; warnings for anything extra that had to be done to pigeonhole the song data in; and so forth – would be nice to have, but at least having the actual song name and not just blah.0. (Also: possibly indicate if an existing file was overwritten or backed up?)

>>4671 I think having the buttons automatically toggle like that would be surprising.

>Information about the file – the file format; number of patterns, samples, instruments, etc.; warnings for anything extra that had to be done to pigeonhole the song data in;

That'd be dandy; schism already prints warnings for chopped features. Or at least it did.

> but at least having the actual song name and not just blah.0

The writer opens a temporary file, writes to it, fsyncs, then renames it over the original. blah.0 was simply the temporary name- nobody is likely to be interested in it unless opening the temporary file fails.