Bank data notes based on Research.md

[dijksterhuis]

I will be largely ignoring the arranger and markers file for now.

The markers file, from what I can tell, seems to save the state of the sample edit UI view. That's all. It's fairly unimportant.

My assumption is that swapping banks will break arrangement references, but seeing as I don't use arrangements, I don't care enough to dig into this right now.

So, Arrangements link to Patterns. There's no link between Arrangements and Banks.

Copying Bank01 over Bank02 won't break any existing arrangements that use patterns from Bank01.

Swapping Bank01 with Bank02 (i.e. also moving Bank02 to Bank01 at the same time) will break arrangements that use patterns from Bank01.

The FLEX list has 8 special entries at the end (129-136) which I assume are for the recording buffers.

Yes.

Unspecified values are padded with FF

It depends on what part of the bank you are looking at. P-Lock bytes are 255 when a Plock track parameter assignments is not enabled on a trig. Same with scene assignments to track parameters. Anything 255 in a newly created bank is usually some form of "OFF" or "Disabled" setting, rather than being an 'unspecified' flag.

Most of the bytes in any given file are in use. Well.... most of them. There are some fields/bytes which do nothing, but they are always set to 0 annoyingly.

I also see this repeating pattern, which I assume is either a delineator, or some kind of metadata.

AA AA AA AA AA AA AA AA 00 00 00 00 00 00 00 00 10 02

These are the half-page bit masks for swing trigs:

AA AA AA AA AA AA AA AA

These are the half-page bit masks for slide trigs:

00 00 00 00 00 00 00 00

This bit is is the "Per Track - Length / Mode" settings

10 02
...
per_track_len = 16 (0x10)
per_track_sc = 2 (0x02) -- 1x scale

Regular (non recording) trigs are stored at the following location in reverse binary format

Not sure what you mean by reverse binary format. All trig data is stored as a bitmasks of each half-page of trigs

To get whether a trig is enabled or not, need to bitwise AND each of these array elements against the current value: [1, 2, 4, 8, 16, 32, 64, 128]. Any non-zero output of the bitwise AND operation is an enabled trig, A zero result is a disabled trig.

For swing trigs above, this works out like this:

positions
1 2 3 4 5 6 7 8 | mask value
----------------|-----------
- x - x - x - x | 170

Trig bitmask arrays have bitmasks stored in this order, which is slightly confusing (pay attention to the difference with 7 + 8!):

1. 1st half of the 4th page
2. 2nd half of the 4th page
3. 1st half of the 3rd page
4. 2nd half of the 3rd page
5. 1st half of the 2nd page
6. 2nd half of the 2nd page
7. 2nd half of the 1st page
8. 1st half of the 1st page

edit -- wait, reverse binary. i see what you're saying. hopefully i've just duplicated something you've already worked out already.

TODO: Create a list of machine types -> codes.

Static = 0, Flex = 1, Thru = 2, Neighbour = 3, Pickup = 4.

The parameters/settings states for all machine types are always stored in the data regardless of which machine is active on a track (in a continuous block of 30 bytes -- 5x machine types, 6x settings).

That's repeated for all 8x tracks in a continuous block, so 240 bytes n total.

The next block of data is 24 bytes x 8 tracks for LFO, amp and FX parameters (6 bytes x 4 x 8 = 192 total)

The next block of data is machine background settings. Again, state is stored for all machine types regardless of which one is active on the track. So 30 bytes * 8 tracks = 240 bytes in total.

After that, comes the sample slot assignments. This is 5 bytes of data. First byte is the zero-indexed static sample slot ID. Second byte is the zero-indexed flex sample slot ID. Third and fourth byte never seem to be used. Then the fifth byte is a recording buffer slot ID (can't remember exactly how this works, was a while ago that I looked at it).

The sample slot assignments, again, are repeated for all 8 tracks. So there's 40 bytes of data there related to sample slots.