It would be pretty stupid to make this not optional. Why would one not want to enable it, if this option existed? :)

Also, I just checked again because I thought that I have actually implemented this - if an instrument is not used, it is not rendered to a file. The check is done globally, i.e. for all patterns in a file, so if you have a reference to an instrument in a pattern that does not appear in the order list, it will be rendered nevertheless.

I think you mean '..to make this optional..' above..?

Okay, 99% completed then in my eye; how about instead of how requested above, the sub-option be changed to a drop-down/selection box with the following choices:

• Current sequence
• Current pattern
• All (global patterndata)

... or the like..? Of course the 'current sequence' option would only be viable to module types supporting sequences.. Anyone using a file as a project, or using actual projects as templates or whatnot, would hate for this to FORCE a global check... ;)

Again: Why would you wants this to be optional? If the sample is not used in the exported sequence, you will get a nice file with digital silence. I'd rather try to spot unused instrument in only the patterns that are actually exported, rather than asking what to do with them.

Edited my response... you are too quick..!

... and FE current sequence I'm working on has 25 instruments not in use in it's patterns, though they ARE in use in other sequences/patterns......... why would I want to sit through the creation of 25 extra 5-someodd-minute length wav files?!
.... here's another file I work in with 78 defined instruments, in one idea sequence FE there are only 15 in use... heaven forbid I'd ever want to export it's instruments under the current operation (I sure as heck wouldn't do so using 'slow render'...)

and/or: why save-as, a copy of the file if only to cleanup unused instruments? Seems the program's already got functionality built-in; shouldn't it be the user's choice HOW said functionality works? Much of the rest of the creative aspects possible within the program are.

The point: not everyone sees it (nor uses the program) as you do (or would expect, perhaps..) ;)

(ok, done editing..)

Clarified the nature of the actual request to make more clear and consice.

SMALL note, not worth adding a new ticket/issue for... (I promise I'm not searching for extra work needing to be done; I'm just thorough..)

Issue:
Instruments containing extended ASCII in name not exported with proper char in filename

Steps to Reproduce:
Name an instrument so it contains the ö (U+00F6) character. Export it. It's changed on my platform to that of a longhand division sign: ÷ (U+00F7)

=Suggestion:
=Character map appears to be off by 1 character value somewhere... (trying to be as helpful as possible.. to save some time I hope..) I didn't test other instrument names using ext. ascii.... too busy finding other issues at the moment.. :(

Correction: exported name is correct in GUI but incorrect when viewing from command prompt only... Could be a windoze problem.