Curious about the source of the last value in note period table.

[marcel303]

Hi,

I'm curious where you found or derived the values in the last column of this table,
https://github.com/jhalme/webaudio-mod-player/blob/91b7e730db23c26e27e350b5cb29a1634939202b/js/st3.js#L31

I'm writing some tracker routines myself, and found 3628 (or a multiple thereof) used instead of 3624 everywhere I looked.

See https://github.com/schismtracker/schismtracker/blob/master/player/tables.c for instance. It has 1016, 960, 907 as the last three values. Yours has 1016, 960, 906 (off by one).

I doubt you'd actually be able to perceive such a small error. But just curious how come? Did you derive these values yourself and is it the result of rounding?

Cheers,
Marcel

[electronoora]

Hmm, I think I copied them directly from the Gravis Ultrasound S3M player I wrote in 1996-97. The same error can already be seen there:

https://github.com/electronoora/s3mlib-gus/blob/master/s3mcore.asm#L1523

I suspect that back then, I probably had a simple typo in the tool which calculated the full table and printed out the data in assembly-includable format. It's likely that I used the formulas from S3M.TXT which again, has the correct values in the table for 4th octave:

https://github.com/lclevy/unmo3/blob/master/spec/s3m.txt

Kinda funny how a typo from over 20 years ago comes back to haunt me. :D

[electronoora]

Interestingly, though - if we use the ratio between semitones (2^(1/12) or approximately 1.05946), we can calculate the following values for 4th octave if our period for C4 is 1712.00:

1712.00, 1615.92, 1525.23, 1439.64, 1358.84, 1282.57, 1210.60, 1142.65, 1078.52, 1017.99, 960.86, 906.93

[marcel303]

Ah hey sorry I didn't get back to you for almost a year!

It's interesting to hear the backstory. Yeah, sometimes typos go unnoticed for long periods of time. I went over some old code of mine recently, and I found the reflection of some meta blobs wasn't rendered correctly. Incorrect normals, sphere mapping messed up. Shock! Horror! ;-)

[marcel303]

By the way, I kinda gave up on writing my own routines, and instead decided to resurrect a really old library, that I was using back in the day, called jgmod. I know it's not the best player in the world. DUMb being better/more precice, but it has easy access to track/channel data. Which is interesting for me, since I'm interested in reinterpreting the channel data (volume, panning, pitch) as a creative experiment. I added some basic IT support to jgmod, and got at least the loading part working, and pitch slides are now correct (linear vs amiga). Downside is jgmod was never built to support NNA (no virtual voices or consideration for them throughout the code base), so I will settle on having only basic IT support. Many IT files play fine without NNA, often don't even use it.