pouët.net

I'm creating a bugfixed+improved version of FT2.09a called FT2.10, and need some help from users that have used FT2 a lot. Do you guys know about any bugs that I should fix? Also please take off-topic comments like "no one cares about FT2 anymore" etc elsewhere.

I have already fixed these:
- "Cut Pattern" on patterns with a length of 256/$100 would crash the program
- Editing unallocated patterns with a length above 204/$0CC would make an overflowed value and crash the program during memory allocation
- Illegal Bxx (Position Jump) usage would mess up the GUI (scrollbar)
- XM effect EFx (x >= 4) + a note would freeze FT2 (jumping to wrong label in replayer code)

you've pretty much covered everything i encountered for all those years.

Alright, that's good to hear. Maybe other people know about more bugs though. Also I meant XM effect E7x, not EFx. Too much .MOD player coding. :-)

Is this the C/SDL2 clone, or a new DOS version? Your site says the FT2 authors allowed you to release source code, does that include the original Pascal and assembly?

This is a new version of the original FT2 program for DOS using the Pascal/asm code. I'm not allowed to share that code.
The clone is also somewhat based on ported code from that, but I recently got permission to open source the clone even if it contains directly ported code.

There's the age old sample fine tuning in the instrument editor not being correct (I suggest either display it in the number of steps it actually has or increase the resolution to match how it's displayed now). The CD-Dump functionality was more or less useless unless you had the exact right hardware so I guess it can be removed. Let's see if I can think of anything else, I believe there's more stuff.

Yeah, sample finetunes have 5-bit resolution since they bitshift it to the right by 3 in the replayer. I want to leave it like this though, because other replayers support the full 8-bit resolution. I'm going to make the WAV loader change the finetune + relative tone to closest match the WAV frequency, and then it's a nice bonus the the frequency is even more accurate if you load the tune in another replayer, maybe. I'm not sure though, will have to think about it. The CD-Dumper is definitely staying, even if it's picky.

I fixed quite a few more things. Here's a list that I'll keep updating from time to time: https://pastebin.com/pDNtJtqb

I'm not a musician. I just tried it out on macOS High Sierra, works fine. The bundled modules are awesome. I remember FT2 back in the 199x. Great tracker. Kudos for porting and fixing.

Thanks. I am however making a bug-fixed version for DOS right now, this thread is not about the FT2 clone I have made.

640x480 mode (or at least letterboxed 640x400), maybe? (default ft2's 640x400 looks like crap on LCDs)

Yuck.. That would require changing a lot of hardcoded framebuffer access code. I also have no experience or knowledge with VGA registers and stuff like that. Sorry, but I think it's not going to happen.

even letterboxing? (or even just having it blank on the bottom)

sure it can be done much easier way ;)

1. When using more than 16 channels on gravis, the sound quality drops.

2. Samples (especially noticable when using drumloops) plays at different speeds when FT2 is used with gravis in DOS, gravis in win95/98 and SB in FT2.

3. (not a bug, but really annoying) The volume envelope (and panning envelope) could really be improved with some kind of indicator how many ticks is between each point.

During MOD (and S3M?) playback: It would be nice if one could choose between mono panning, complete stereo separation and somewhat separated instead of just having mono only.

1) This is a limitation in GUS
2) No idea how to fix this, I lack the knowledge
3) Not sure how I would do this, there's barely any room left in the instrument editor for new text
4) Nope. FT2 is a tracker that is always in "XM mode", there's no way to switch. The tracker never knows if you're editing a MOD or an XM, so hacks like that would just be confusing.

iirc FT2's mod exporter sets a non-looping sample to replen value 0, which crashes out Amiga trackers when you load them into it. (you have to set the replen back to 2 before playing the track)

Ahh yes, that's an easy one to fix. Will do.

1-4. thank you for answers.

1. (continued) I always wondered how GUS would sound different if it was mixed in software instead of on the chip. If it would solve the timing issues. Also, these "GUS down quality issues" weren't in Impulse Tracker 2, are you sure it can't be made? (I'm not a coder of DOS-apps so I wouldn't know).

5. I think renaming the channel index to start at 1 instead of zero-indexing is a mistake. So many other things in FT2 start at zero in the tracker. Many trackers throughout the years have "copied and improved the FT2 design" which always made them horrible to use. If you make changes please make them an option, customizable, not permanent.

All being said, thank you for working on this project.

FT2 is a bug that you can sometimes make music with.

Yes they were there as well, but IT also had a "software-rendered" GUS driver, maybe you were using that one. Given that it easy to reach more than 32 simultaneous voices in IT, many GUS owners probably used that driver.

Actually I do have something useful to contribute: when you start FT2 in SB mode, load a module, and switch to the GUS driver, sometimes it doesn't load the samples into GUS RAM. Unfortunately I'm not 100% sure of the exact conditions to make this happen.

Was actually hesitant to post this due to the sheer epicness that resulted the one time I ran into it (see link.)

Related off-topic epicness: This is what it sounds like when Imago Orpheus runs out of sample memory on an AWE64 Value...

While I understand that it can be inconvenient in certain situations, is it really a good idea to fix it? MODs sound different in FT2 and e.g. Protracker, and I believe some players use the replen field to identify FT2 MODs so they can play them back correctly in FT2 mode.