Please document the .pti instrument format

[jaap3]

I'm really excited by the introduction of .pti, the new instrument format. Is Polyend planning to provide documentation on the file format layout? I.e. how to load the .pti file and read both the sample, as well as all instrument parameters like envelope settings, sample playback type, wavetable position, and so on.

The announcement made me think of XM.TXT that came with FastTracker 2 (but with pull requests 🙂).

I'm hoping documentation will allow third parties to develop software that can load, edit, preview, maybe even create new .pti files.

Thanks for this amazing device and continued support.

[jaap3]

I did some minor reverse engineering and was able to extract .wav files from .pti files using a simple Python script:

https://gist.github.com/jaap3/62adfc81d1a7347a0e64677ab40fe332

I figured out the .pti file header is 392 bytes by first creating a short .wav file, importing it into the Tracker, extracting the .pti file and finding the offset off the audio data using these Python scripts:

https://gist.github.com/jaap3/db27f377056e45d482ab06c69a6c2915

I haven't spent much time investigating the header contents. I've only figured out the first two bytes are always TI and the instrument name starts at byte 21.

[dimatura]

The length of the old-style .mti files used by the tracker is also 392 bytes. So I'm guessing a .pti file is just an .mti concatenated with a .wav, which would make sense.

As you mentioned, the .mti files do bear some resemblance to other tracker instrument formats -- it might be coincidence, but .mti is also used by mad tracker. At first glance, the layout of the .mti seems a fairly straightforward binary dump of the instrument parameters, but mapping out the values would take some trial and error.

[jaap3]

So, I've spent some time thoroughly looking through .pti files and written down my conclusions here: https://github.com/jaap3/pti-file-format/blob/main/pti.rst

This is a fairly complete overview of what the bytes in the .pti file header mean. It's not official, but it's a start :-).

[ejconlon]

Great job on the reverse-engineering, @jaap3 !

Polyend, providing an answer to this would allow third parties to more easily provide sample packs for the Tracker and would enable people to write tools for SoundFont conversion (basically solving https://github.com/polyend/TrackerBetaTesting/issues/1346).