Greetings my fellow earthlings.
I come in peace and bring gifts.
So, I have this genourmous sample collection that I ported over to my Octatrack, only to discover that Octatrack doesn’t slice stuff automagically, but you have to slice the samples manually. Normally that’s fine, but I just had waaaaay too many samples to start chopping them off by hand.
I tried to look for a tool that would chop n slice samples, but I didn’t find anything specifically for the Octatrack (that would write the .ot file), only the Octachainer came close (awesome software btw) so I took out Processing and typed out a crude hack n slash piece of script to do it automatically.
The script calls out for Aubio, which is an audio analysing commandline tool. Aubio sniffs an audio sample and finds all the juicy transients (can be beat or note) and flags it as a slice. The script then grabs those flags and injects them into a .ot file that the Octatrack can read.
Now, a fair warning - I’m really crap at programming, so there are some beginner mistakes everywhere in the code - so don’t expect a ultrasuperfast tool that magically makes coffee for you while it slices your samples. It’s a very basic brute force tool to get the slices going, so you can tweak the other settings in the Octatrack later.
Stuff that works:
- Open any sample and slice it automatically
- Open a folder and process all samples in it (the script doesn’t touch the samples, just reads and analyses them)
- Create a .ot file that contains the slice information for the Octatrack for each sample
Stuff that doesn’t work
- Update: This should work now >> Checksum is wrong, so Octatrack will throw an error when opening the sample. All data is intact and the slices work. I tried my best to wrap my head around Java’s unsigned / signed bit crappola (which is not as handy as in C++) and just blew a fuse with it. If someone knows how to properly calculate it, would be awesome.
- Tempo detection doesn’t exist. Right now it just reads what ever is written on the sample filename. If your sample is called ‘220_drumloops_128_top_loop_09.wav’, the tempo will be set to 220 as it’s the first high number in the filename. So, put the tempo as the first big number, like "128_220_drumloops_top_loop_09.wav’.
- Loop settings in the .ot are wrong. Some of the stuff went waaaay over my head so it just writes in ‘whatever’. Octatrack will correct it when it reads the file. And says “lol wut”. I’m planning on learning this stuff and making sure that all the bars and loopy thingies are correct. Lack of documentation makes the job a tad hard though. Most data should be in the ballpark.
- Doesn’t recursively read folders - this can be added if needed. Best is to process files in small bursts.
- Samples come with a plethora of weird naming conventions, so expect things to break if the parser encounters something I haven’t anticipated (lot of possibilities out there). I used this to process a number of my own folders and it seemed to go smoothly. If Processing hangs, kill it with fire and start again.
- Slicing might be wrong. This is due to how Aubio reads and interprets the data. I’ve included a couple of the main settings at the top of the script so you can tweak stuff if some slicing is a bit … ‘off’. But in general, snappy stuff should be sliced ok. I encountered some super loud EDM loops that got chopped a bit funky, because the levels were so high all the time (ie. not much difference between loud and quiet), so Aubio got a little confused.
- Single hit samples. There are a number of rules that I could set in the script to prevent single hits like drum hits from being analysed, but I have my loops separated so I didn’t have the need yet for it. Let me know if this is a thing that you want.
- It will not make you coffee
The code is free to share and to modify to your needs. Go and slice stuff up. But if your entire sample library goes up in smoke, you have been warned now to make a backup before you do anything. I will take no responsibility.
Stuff that’s required >>
Windows. Sorry mac users, I don’t own a mac so I can’t test this over there. In theory it should work, in practice though, most likely Java will start to nag you about the buffered reader and the byte order. I have no knowledge on how to get those running if they don’t work out of the box. : /
Processing >> https://processing.org/download/
It comes in a handy zip file so there’s no need to install anything, it should work out of the box.
Processing’s audio library ‘Sound’
When you open up Processing, go into the top menu, select “Sketch” and “Import Library” and from that list select “Sound”. Sound library is a necessary evil that tells us what samplerate and duration the loop is. I was hoping Aubio could’ve told that info, but welp.
Aubio >> https://aubio.org/download
Commandline tool that analyses audio files. This one also comes in a zip file so it’s easy to get running. Then, in the script, point it to the ‘aubioonset.exe’ file and things will start working.
The Script >> https://pastebin.com/eKPKVxKQ
This is the thingy that will do all the other thingys for you while you fiddle with your thingy. Create a folder like “octaslicer” and put this script in there and name it the same as the folder and add the processing extension to it, ie. “octaslicer.pde”. The name doesn’t matter, it can be anything. Open it up on Processing and make sure there are no errors in Processing’s output window. Press run after you’ve added the path to the ‘aubioonset.exe’ file in the script. Use / in the path name instead of \
I would include all of these in a single package, but I don’t know (or care) about the klunky licensing of each library and tool so … apologies. Also, my code might violate some GPL at some point but this is not meant to be a commercial tool or anything. I just made this for myself and thought I’d share it with peeps that might need something like this. : )
Happy slicing,
Jp