Hey folks. Last week I developed a python-based CLI tool for creating PTI Instruments.
Initial purpose of the utility python CLI app is threefold.
Create .pti forward-looping instruments with clean loop points that are encoded in a wave file sample. Currently Polyend Tracker doesn’t read these loop points and thus makes clean looping of instrument samples rather challenging.
Create .pti beat-slicer/slicer instruments from a series of individual wave-files to create drum-kits and perfect conversions of previously sliced loops (REX for example) into .pti loops.
Batch convert wave files into individual pti instruments. For individuals making sample packs or libraries for distribution, this may save time over individually creating the .pti files in Polyend Tracker directly.
The only thing is…what’s the point creating an instruments, directly from the sample? I mean, of course if you want preserve the original sound, for example with vintage drums machine, or very distinctive sounds, ok, that’s so handy…but…the beauty of a sampler is to have control over the original samples, being able to transform and put, in this case, in a .PTI , sharable format. This is only a personal point of view, and, this tool can be VERY handy in many scenarios.
1 turn a folder of samples into a kit, ready to use, pre-sliced. So it makes creating a drum kit pti super easy. Also if you use Recycle and export as individual wave file slices you can convert your Rex library into PTI files without having to redo all of your slice work in the tracker.
It reads loop points that are embedded in the wave file. So if you use something like Endless WAV to set up loop points in the file or an auto-sampler that embeds the loop points in the wave file during sampling, it can create a PTI that has those loop points carried over perfectly. I found it to be a PITA to set up seamless loop points in the tracker. This solves that problem elegantly.
Sample pack makers who want to at scale create the pti files from a folder of wave files. This will save those users a step of having to save as pti each wave file. This is assuming they will also want to tweak the settings of each pti file manually after the bulk conversion. It’s just a connivence for those who want to migrate their sample libraries to the format.
One other point. For python developers, because this is a python library, this can be integrated into other python workflows for conversion. For example there are python libraries for reading soundfonts and the like. This means that someone could set up their own conversion reads the soundfont, exports to wav, then calls this library to then convert to pti. Something like that. There’s many possibilities, this is just a starting point.
I have to trim the starpoint o earch PTI otherwise it clicks.
I’ve tested with various input formats and I always have a clipping added at the start of the converted file.
It happend merging multiple waves or ever just single samples.