Interesting... I took a peek at the source. There was stuff added to 2A03 since 0.3.0 that is incompatible with it, so there could never be a way to convert back everything.
It looks like there is some old code (LoadInstrument function and an INST_VER define) that was supposed to be used to check this, and reject the load, but it doesn't actually get called. Instead the loading is done in ReadBlock_Instruments, which doesn't have the same version numbers (uses BLOCK_VERSION=2, not INST_VER="2.3" like the LoadInstrument version), and doesn't even check that version number for validity.
So... after looking at it I think your ability to load new files in 0.3.0 is actually an unintended bug. Kinda weird.
Since I was in there, I decided to make you a hacked 0.3.0 executable. (The altered source file is included if you want to see what was changed.) This will load the newer sequences, discarding release point data that is incompatible with 0.3.0. So, it's not perfect, but this was never designed to be able to read data from the future. (Also, some newer files seem to cause crashy/undefined behaviour when loaded into 0.3.0).
My conclusion is the same, though. Your being able to load this stuff at all with 0.3.0 is a bug. There is version checking code in there, but at some point I guess it got orphaned.
I would not recommend that jsr go back to the old format for a future release, as we would be losing functionality. I'd actually request that version checking be put back in for the next version (and probably'd be a good idea to remove the orphaned code as well).
You, sir, are a genius; this is exactly what I was looking for in terms of bringing back some measure of functionality.
I understand that VRC7 & FDS tracks will crash the program; that's more than expected. But I didn't know exactly how much the instrument code was changed to the point that otherwise global functionality would simply die off. I agree on one thing, though; better version-checking is what JSR really needs in his next release.
Props, rainwarior!
_______________________
Technology: the one thing that's hated & cursed at by all engineers, technologists, scientists & technicians!
rainwarrior: LoadInstrument is used to load FTI-files and is different from instrument data in FTM files, so that's why version numbering is different.
Anyway, newer versions have proper version checking so now it'll just display a box about incompatible versions instead of crashing. The original idea was that files would always be compatible but that didn't work.
Ah, okay. That explains that code. I didn't think of FTIs.
I don't know if always-compatible is really possible. You could try to work it in such a way that instead of refusing to load, an old program there are tags in the file format that identify the new/incompatible bits and they can be discarded, retaining some partial compatibility (probably with a warning message). But... the only real way to have infinite compatibility I suppose is to never change the format again. :P
I think backward compatibility is a good enough goal. FT is ridiculously easy to "install"; most people are probably okay with upgrading when necessary (TechEmporium excepted).
) 
