[PROJECT] ProTracker v2.3D clone for modern platforms

[8bitbubsy]

The problem with using SDL2 is that it has no support for PPC, AFAIK... It would put PPC Macs out of the equation, and I constantly make a build for those.
I could try the code with SDL2 and see if the SDL_Flip() is faster, and if so, try to use some #ifdef magic to make the code compilable with both SDL2 and SDL1.2.

[tolkien]

Would be interesting to know it. Don't know how mature is the MorphOS SDL2 port but yes, would be interesting.
You are the man olav!

[8bitbubsy]

Just took a look at SDL2.0, and it looks like a pain in the *** to maintain SDL1.2/SDL2.0 compatibility with #ifdefs. So I'm not going to bother, it probably won't be much faster anyways.

[tolkien]

No problem mate. Keep the good work.

[no9]

This post is from 2011 so watch out!

Originally Posted by 8bitbubsy

I am glad to announce that I have finally fixed the annoying .. what should I call it... "Paula sample swap delay" bug?
This is NOT the same as the well known "swap sample on the fly" PT1.x phenomena.


- This only applies to a "new sample number" - e.g. a sample number that is different from the previous one. -
Sample 5 must finish playing (or reach its loop end) before Paula sets its new sample pointer/loop points to sample 0F! If the sample is still playing while it hits 0F, the 0F will be triggered when 05 is done. However, it will instantly set the sample volume to 0F's sample volume, so this only applies to loop points and the sample data pointer.
If you put a note number in front of 0F, it will of course trigger instantly (unless you put 3xx/5xx there too, then the exact same rule apply).

This is a very special bug, and I guess I am amongst the very few people to be aware of it. Several MOD songs are affected.

Right. I discovered it in late '90ties and applied it once as an experiment in this mod https://modarchive.org/index.php?req...id&query=98944


It interleaves sample numbers 11 and 12 in song but the latter one is there only for setting volume. Before sample 12 is reached, 11 is set again so 12 is never played but contributes to sample 11s volume.

[8bitbubsy]

The ProTracker 2.3D clone replayer is directly ported from the original assembly replayer code these days (+ I wrote a Paula "emulator" for register update after read, so that sample swapping works exactly the same as on Amiga). It's much more accurate than it used to be back then. Also I have learnt a lot since 2011 btw, so I wouldn't really quote something that old...

[no9]

I quoted it just to place my post in the context, since I don't see forum to link my reply to the original post. I'm not a coder and I'm more interested in tunes that did use this bug/feature or was affected by it, incidentally or not. Did you find any other examples of Protracker modules, besides those 3 you listed in the original post, which I refer to?

[8bitbubsy]

I have probably found many throughout the years, but nothing that I remember in particular right now.

[Hewitson]

Does this have anything to do with the bug in Vroom/VF^CPY intro?

[8bitbubsy]

Originally Posted by Hewitson

Does this have anything to do with the bug in Vroom/VF^CPY intro?

Actually yeah, it's related to sample swapping but also a replayer bug. I found the issue after looking around for a bit.

The replayer in the VF cracktro has a design error with restarting the song after the last position was played. Instead of setting the current pattern to the first entry in the "order table", it sets it to 0. This is wrong. In the song, position 0 has pattern 1, position 1 has pattern 0 (according to the table), and so on.

Pattern 0 (pos 1) starts with a portamento on the lead channel, so after the song wraps it goes from sample 7 to sample 6 with the portamento. The combination of sample swapping and portamento can give really strange results, I don't fully understand how it works to be honest. The song wraps fine in ProTracker (and my clone).

[Mickoz]

Sorry to post in an old thread, just wanted say this is awesome and thank you for making it.

[no9]

It plays wrong pattern after the song loops. That observation is correct. But it has nothing to do with sample swapping. You can get exactly same results in Protracker if you set first played pattern in the song to pattern 0, even if sample number is not changed inbetween.

[8bitbubsy]

Originally Posted by no9

It plays wrong pattern after the song loops. That observation is correct. But it has nothing to do with sample swapping. You can get exactly same results in Protracker if you set first played pattern in the song to pattern 0, even if sample number is not changed inbetween.

Turns out you're right, so the reason it fails (when wrapped wrongly) is because the portamento slide is not big enough to reach the destination period (note). I initially thought it was related to the actual sample swap happening, because I remember sample swap + 3xx being quite strange.

[no9]

Precisely.

Anyway, that module implements by hand 'modulation by loop shifting' I mentioned somewhere there http://eab.abime.net/showpost.php?p=...&postcount=114. Frame shifts in samples 06-0B which are exactly the same otherwise.

Too bad we never had a tracker that allowed us such things. By use of commands or automating it with envelopes or kind of lfo's. This could enrich chiptunes sounds on Amiga a little bit and save storage space and sample slots like in the case of track "Monday".

[8bitbubsy]

Yes I've seen that in a couple of modules, classic trick to get multiple timbres out of the lead/waveform. This is pretty much the most common reason for using sample swapping.

[no9]

Of course it is common way to modulate sounds in chiptunes. I'm saying that in theory there are smarter ways to achieve the same, or even better results without going beyond standard capabilities of Amiga hardware. And without throwing much of a burden on CPU. Unfortunately that path of tracker evolution left unexplored on Amiga.

[Hewitson]

Originally Posted by 8bitbubsy

Actually yeah, it's related to sample swapping but also a replayer bug. I found the issue after looking around for a bit.

The replayer in the VF cracktro has a design error with restarting the song after the last position was played. Instead of setting the current pattern to the first entry in the "order table", it sets it to 0. This is wrong. In the song, position 0 has pattern 1, position 1 has pattern 0 (according to the table), and so on.

Pattern 0 (pos 1) starts with a portamento on the lead channel, so after the song wraps it goes from sample 7 to sample 6 with the portamento. The combination of sample swapping and portamento can give really strange results, I don't fully understand how it works to be honest. The song wraps fine in ProTracker (and my clone).

Interesting. Thanks for the detailed explanation!

[8bitbubsy]

Originally Posted by Hewitson

Interesting. Thanks for the detailed explanation!

My theory was not fully correct, please read the nexts posts after that one.

[no9]

I have an issue with MOD2WAV function. It renders wav file twice long and the result seems buggy.

[8bitbubsy]

I just gave it a quick test and it seems to work fine here...
What OS are you on, and what PT2 clone version are you running? The latest version is v1.02: https://16-bits.org/pt2.php

If it still fails with the latest version, then maybe it's a bug with the specific .mod you are using.