.it vibrato.

Been working on a hopefully-sample-accurate-once-i-get-stuff-sorted .it player. Currently aiming for IT 2.11 accuracy, as that has the nicest .wav writer in terms of being able to get sample-accurate. Furthermore, IT 2.11 isn't that much different in its playroutine from IT 2.14 patch 5 (most notably it doesn't have filters, but tbqh I don't care about that yet).

Vibrato has proven to be the biggest pain in the ass so far to get right (barring maybe Amiga slides). The most annoying thing is that you basically need bat ears to tell the difference between what IT spits out and what your average Joe Playroutine spits out.

Firstly, determine whether you are using Amiga slides or linear slides. I haven't fully sussed out Amiga slides yet, but my estimate of AMICLK=8363*1712*64; freq = (AMICLK/(AMICLK/freq - extra_fine_slide_up*64)); isn't too shabby, but tends to be off by 1Hz in a few places and I honestly don't know why (I think this happens with down slides but not up slides, don't ask me why).

Now, you update the offset by the speed FIRST. Then:

v = vib_depth*table_to_use[vib_offs];
v += (v < 0 ? -7 : 8);
v = (v < 0 ? -((-v)>>4) : v>>4);


(If you can make this more elegant, please do!)

If you're using Amiga slides, do an extra fine slide by v.
If you're using Linear slides, then, if abs(v) < 15, do an extra fine slide by v, otherwise do a normal slide by v/4 (clamp to 0).

Now, onto retriggering.

I don't yet know what retriggers vibrato, other than this case:

C-5 01 .. Hxx <-- going as usual
... .. .. Hxx

... .. .. Hxx

... .. .. Hxx

... .. .. Hxx

C-5 02 .. Hxx <-- retriggers! (if you remove the Hxx, it will NOT retrigger.)

C-5 01 .. Hxx

But the most important thing is it doesn't normally retrigger on a new note.

Important XM notes.

As it turns out, whoever wrote the docs on the .xm format are a bunch of dirty liars. So I'm going to guide you through some things you need to know.

When you have to implement the XM file format in your loader, keep in mind that Triton's philosophy goes a bit like this: "If it's zero or empty, don't store it"

This is absolutely crucial. If you're lucky(?) enough to be able to dump byte data straight into a structure, what you do is you zero out the structure, load up to what the length says (after subtracting 4 in most cases), and skip any bytes that would otherwise overflow past the structure size and crash your program.

Some notes on sizes.

These include the bytes responsible for denoting their "size" in the calculations:

• 60 4 (dword) Header size
• ? 4 (dword) Pattern header length
• ? 4 (dword) Instrument size

On the other hand, these don't:

• +7 2 (word) Packed patterndata size
  
• +29 4 (dword) Sample header size

There's a very real chance I may have this wrong - if I do, please tell me!

Some notes on everything not stored being treated as 0.

If the field "Packed patterndata size" is set to 0, the pattern is NOT stored in the file but it MAY be used by the song.

If your loader is handling block sizes correctly, you can go ahead and "load" it anyway.

If the number of samples > 0, then the this will follow:

Ditto.

0 17 (char) ID text: 'Extended Module: '

I'm not even going to paste the original text, just the correction: IT'S A CAPITAL M.

The current format is version $0103

No it's not. It's $0104.

+10 2 (word) Number of patterns (max 256)

Unlike what another corrections doc says, this is actually correct. It does refer to the number of patterns and not the number of the last pattern. I think the guy who wrote that doc may have implemented his player wrong.

+26 1 (byte) Instrument type (always 0)

Pretty sure all types I've seen are 8. Personally I just ignore this byte.

Even 16-bit data is stored as delta values. (It only makes really sens to store every other byte as delta value, but this is as easy. Oh, well.)

This is outright wrong. XM stores 16-bit samples as normal delta samples, not byte delta samples as documented here.

Some notes about samples.

The sample headers are stored sequentially, and THEN the sample data blocks are stored.

Length, Loop Start, and Loop Length are all given in bytes, as opposed to samples which are used in IT (irrelevant for S3M as ST3 doesn't actually support 16-bit samples, but I suspect they are canonically measured in samples too for non-ST3 players).

That's all I can think of off the top of my head.